Как стать автором
Обновить

Готовые кластеры Kubernetes или самостоятельное развертывание? Что выбрать

Уровень сложностиПростой
Время на прочтение9 мин
Количество просмотров8.8K
Всего голосов 33: ↑31 и ↓2+39
Комментарии5

Комментарии 5

спасибо за статью очень познавательно. Хотя очень забавно слышать что развертывание обычного кубернетес кластера может достигать дня и что менеджед кластер может подойти для неопытных админов. К сожалению одним из важных атрибутов оказывается стоимость на поддержку кластеров особенно при раздутом рынке кадров. По своему опыту скажу что менеджед куб не подошел из-за жестких ограничений в кастомайзе. Никто из менеджед провайдеров так и не научился включать фичи гейт по требованию. Ограничение на исправление в Яндекс клоуде цилиум конфига вообще добило. Пришлось пилить свой менеджед куб на терраформа который поднимает куб за какие то 3,5 минуты

Спасибо, что поделились опытом) А сколько у вас ушло времени на такой handmade? И вы один поддерживаете собственно созданный менеджед куб или есть команда?

Если говорить в рабочих днях два месяцах фултайма, а так пол года крафта после основной работы. Поддерживают два человека, а так можете посмотреть в профиле у меня, недавно писал статьи по опыту проектирования такого рода кластеров.

О! Из моего опыта приходилось иметь кластера готовые как на сбере, так и на vk (но он был молод еще год\два назад).

Если выбираете такое сегодня, то готовьтесь к тому, что у них будут баги (сейчас уже меньше), которые могут подпортить жизнь вам и sre специалистам. Либо не баги, а плановые замены стораджей например, что может повлиять на миграции ваших stateful сервисов. Вас будут информировать постоянно о каких-то работах у них там. SLA может снизиться.

Коллеги, гораздо проще свое всегда иметь и дешевле. Да, на старте будет сложновато. :)

Managed k8s часто имеют неприятные Нюансы, которые хоть и упомянуты в доках (часто вскользь, зачем пугать людей?), но кто же внимательно их сразу читает. И тут начинается самое веселье. Напр из AWS EKS: нельзя свой CNI, иначе webhooks придется делать на hostport, раньше было ограничение pod-per-node из-за особенности работы их eni (сейчас можно выделять IP ноде сразу подсетями). И такие wtf встречаются не редко.

Так же managed не всегда упакован всем необходимым набором (cert-manager, coredns, mesh, monitoring, и тд), а из моего опыта поддержка всего этого набора и занимает основное время ухода за кубером. Так что в итоге все равно собираешь свой дистр. Радует правда, что в последние время с этим становиться лучше.

Из жирных плюсов managed - часто широкая и хорошо работающая интеграция с остальными сервисами внутри провайдера. Ну и саппорт, особенно при обновлениях (напр в интерфейсе у того же EKS сразу пишут какие манифесты сломаются после апдейта).

Зарегистрируйтесь на Хабре, чтобы оставить комментарий