Pull to refresh

Comments 20

Deckhouse активно используется flannel почему не calico ?

Потому что у flannel 6.2К звёздочек на github, а у calico 2.4K. Это, конечно же, шутка. Flannel является очень простой и понятной штукой, мы отлично понимаем её возможности, плюсы и минусы, с самых первых инсталляций сделали свой выбор в пользу flannel. В режиме host-gw flannel обладает хорошей производительностью. В Deckhouse есть модуль network-policy-engine, который предоставляет управление сетевыми политиками, под капотом используется kube-router, всё это работает вместе с flannel.
Это не значит, что flannel — идеальный cni, который лучше, например, calico. Условно, flannel — это отличный молоток, нам надо забивать гвозди, мы берём flannel. Надо будет заворачивать саморезы, нужен будет шуруповёрт, будем использовать другой инструмент.

Все-таки я в упор не понимаю — почему не использовать "голый" Kube-router, а не делать микс из ДВУХ(!) сетевых плагинов (Flannel+kube-router). Очевидно же, что два плагина это более сложная система, чем один.


Честно — со стороны — выглядит, что попросту сначала вы обкатали flannel, набрали на нем экспертизу, а потом прилепили сбоку Kube-router, чтобы закрыть вопрос NP. Исторически сложилось, что уж там.

Честно — со стороны — выглядит, что попросту сначала вы обкатали flannel, набрали на нем экспертизу, а потом прилепили сбоку Kube-router, чтобы закрыть вопрос NP. Исторически сложилось, что уж там.

В корень зришь.

Ведь в статье ровно так и было написано ;-)

Исторически сложилось, что в части кластеров под управлением Deckhouse активно используется flannel …

а планы какие-то есть менять плагин? Да, по ходу дела — будет две разных ветки ("старая" c flannel+kube-router и "новая" /TBD/), но что поделать?

У нас уже есть алгоритм последовательного переката нод. Мы в него лишь добавим логику лейблов и nodeSelector'ов, чтобы постепенно перекатить DS flannel в пользу DS cilium.

Правильно ли я понял, что при обновлении воркер узлов, вы просто обновляете kubelet и рестартуете его?
Как я понял, из кучи кластеров и нод, у вас всего один раз он не поднялся. Просто в доке советуют делать drain, но это так долго =(. А вы обновили столько нод, и практически в 99.99% случаев kubelet успешно поднялся, похоже в доке перегибают с осторожностью?

Drain был необходим при обновлении до 1.16, я писал про это.
Обновление с 1.15 на 1.16 приводило к рестарту контейнеров на узле, поэтому приходилось выполнять drain узла, что в случае большого количества stateful-приложений приводило к необходимости выполнять работы в согласованные окна и требовало особого внимания инженеров.

При обнолвении на 1.17 и выше рестарта контейнеров нет, поэтому мы не выполняли drain. Либо в доке просто прилипла информация о необходимости drain'a, либо действительно излишняя предосторожность. У нас проблема действительно возникла только на одной ноде. Следует отметить только один момент. В момент обновления kubelet'а нода на короткое время переходит в NotReady, если у вас в кластерах какие-то кастомные настройки эвикта подов в случае, если нода недоступна, то могут начаться активные перекаты подов.
Не совсем понял как было обновление в облачных средах. Ведь там все делается через интерфейс управления облаком — конечно я понимаю, что это просто вызов команд для обновления kubernetes, но ведь у разных поставщиков услуг могут быть немного разные вызова и особенности.
Про железные не сказали как обновили, kubespray playbook переписывали или просто бинари подменили?
Не совсем понял как было обновление в облачных средах. Ведь там все делается через интерфейс управления облаком — конечно я понимаю, что это просто вызов команд для обновления kubernetes, но ведь у разных поставщиков услуг могут быть немного разные вызова и особенности.

У нас своя разработка (Deckhouse), у которой одна из главных идей — это поддержка одним и тем же дистрибутивом разных провайдеров, что позволяет разворачивать одинаковые кластеры в разных облаках (и даже мигрировать при такой необходимости). В облаках мы используем не managed-решения провайдеров (AKS, GKE…), а их вычислительные мощности, куда ставим свой Kubernetes (грубо говоря, мы раскатываем там свой managed K8s). И поэтому обновление происходит у разных провайдеров аналогично, оно никак не зависит от специфики того или иного облачного managed-решения.

Про железные не сказали как обновили, kubespray playbook переписывали или просто бинари подменили?

Соответственно, bare metal — это просто еще один вид инфраструктуры, которую поддерживает Deckhouse помимо разных облачных провайдеров. Kubespray мы не используем. А про подмену бинарников лучше расскажет автор :-)
то на момент, когда версия control-plane в облачных кластерах соответствовала 1.17 и 1.18, были отключены компоненты

А как это сделано, вручную? Или Deckhouse при обновлении умеет автоматически выкручивать replicas этих компонентов в ноль?

Да, Deckhouse автоматически это делает, только не replicas в 0, а убирает Deployment из helm-релиза.
… мы используем Docker в качестве Container Runtime, что тоже приносило нам регулярные проблемы в виде зависших в воздухе Pod’ов в статусе Terminating.

Я так и не понял, вы от докера избавились? Что выбрали?

Статья очень интересная получилась. Спасибо.
От Docker пока не избавились, в 1.18 появился фикс, который решает нашу проблему. В Deckhouse есть поддержка Containerd, планируем плавную миграцию.
Обновление версии control-plane до версии 1.17;
Обновление версии kubelet на узлах до версии 1.17;
Обновление версии control-plane до версии 1.18;
Обновление версии kubelet на узлах до версии 1.18;
Обновление версии control-plane до версии 1.19;
Обновление версии kubelet на узлах до версии 1.19.

Интересно, а пробовали обновлять кубелет одним рывком с 1.16 до 1.18? SIG Node обещает n-2 совместимость, можно сэкономить на дрейнах \ ребутах

Мы проводили обновление без дрейнов и ребутов. Я чуть выше ответил почему. Мы не пробовали в продах, но можно было обновиться по более простой схеме, перепрыгнув через пару версий, но итоговую схему посчитали более безопасной, тем более написанная «автоматика» заточена на обновление по одной версии вверх.
Пробовал с 1.17 до 1.19, сначала контрол плейн(каждую минорку, иначе кубадм не дает), потом сразу кубелет 1.19. Все ок прошло
Only those users with full accounts are able to leave comments. Log in, please.