Комментарии 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. Надо будет заворачивать саморезы, нужен будет шуруповёрт, будем использовать другой инструмент.
Это не значит, что flannel — идеальный cni, который лучше, например, calico. Условно, flannel — это отличный молоток, нам надо забивать гвозди, мы берём flannel. Надо будет заворачивать саморезы, нужен будет шуруповёрт, будем использовать другой инструмент.
Все-таки я в упор не понимаю — почему не использовать "голый" Kube-router, а не делать микс из ДВУХ(!) сетевых плагинов (Flannel+kube-router). Очевидно же, что два плагина это более сложная система, чем один.
Честно — со стороны — выглядит, что попросту сначала вы обкатали flannel, набрали на нем экспертизу, а потом прилепили сбоку Kube-router, чтобы закрыть вопрос NP. Исторически сложилось, что уж там.
Честно — со стороны — выглядит, что попросту сначала вы обкатали flannel, набрали на нем экспертизу, а потом прилепили сбоку Kube-router, чтобы закрыть вопрос NP. Исторически сложилось, что уж там.
В корень зришь.
Правильно ли я понял, что при обновлении воркер узлов, вы просто обновляете kubelet и рестартуете его?
Как я понял, из кучи кластеров и нод, у вас всего один раз он не поднялся. Просто в доке советуют делать drain, но это так долго =(. А вы обновили столько нод, и практически в 99.99% случаев kubelet успешно поднялся, похоже в доке перегибают с осторожностью?
Drain был необходим при обновлении до 1.16, я писал про это.
При обнолвении на 1.17 и выше рестарта контейнеров нет, поэтому мы не выполняли drain. Либо в доке просто прилипла информация о необходимости drain'a, либо действительно излишняя предосторожность. У нас проблема действительно возникла только на одной ноде. Следует отметить только один момент. В момент обновления kubelet'а нода на короткое время переходит в NotReady, если у вас в кластерах какие-то кастомные настройки эвикта подов в случае, если нода недоступна, то могут начаться активные перекаты подов.
Обновление с 1.15 на 1.16 приводило к рестарту контейнеров на узле, поэтому приходилось выполнять drain узла, что в случае большого количества stateful-приложений приводило к необходимости выполнять работы в согласованные окна и требовало особого внимания инженеров.
При обнолвении на 1.17 и выше рестарта контейнеров нет, поэтому мы не выполняли drain. Либо в доке просто прилипла информация о необходимости drain'a, либо действительно излишняя предосторожность. У нас проблема действительно возникла только на одной ноде. Следует отметить только один момент. В момент обновления kubelet'а нода на короткое время переходит в NotReady, если у вас в кластерах какие-то кастомные настройки эвикта подов в случае, если нода недоступна, то могут начаться активные перекаты подов.
Не совсем понял как было обновление в облачных средах. Ведь там все делается через интерфейс управления облаком — конечно я понимаю, что это просто вызов команд для обновления kubernetes, но ведь у разных поставщиков услуг могут быть немного разные вызова и особенности.
Про железные не сказали как обновили, kubespray playbook переписывали или просто бинари подменили?
Про железные не сказали как обновили, 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 этих компонентов в ноль?
… мы используем 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. Все ок прошло
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы обновляли Kubernetes 1.16 до 1.19… с удовольствием