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

10 антипаттернов деплоя в Kubernetes: распространенные практики, для которых есть другие решения

Время на прочтение 21 мин
Количество просмотров 11K
Всего голосов 39: ↑38 и ↓1 +37
Комментарии 12

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

Почему pod где-то переведен, как «под», а где-то как «модуль»?

Вот не мог понять, что за модули уничтожают.

спасибо, ошибся. исправил везде на под.

Почти в каждом пункте все спорно и есть нюансы. Было бы неплохо это упомянуть.
Вот, например, все конфиги будут в readonly, если следовать рекомендациям по первому пункту. Часть будет применяться только при рестарте пода. Это не всегда возможно. Многие приложения просто не запустятся в таких условиях.
Вместо хелма есть кастомайз, а хелм в хелме в хелме это дикий кошмар, для примера вон попробуйте размотать гитлаб.
И тд. Я к тому, что все делать надо максимально просто. Каргокульт и безумное следование неким бестпрактис — это всегда излишняя трата времени и денег. А типа некие бестпрактис без указания деталей и условий задачи просто вводит в заблуждение и разочарование.

Может я чего-то не учитываю, но я не понимаю, зачем нужен blue/green, когда есть rolling update и staging окружение, близкое к production.
С канареечным понятно — позволяет подвергнуть риску регрессий лишь часть пользователей, и, если скорость реакции на инциденты у разработчиков высокая, а период до полного выката достаточен, то снизит риски.
А что такого несёт blue/green — не понимаю. Разве что как костыль для сокращения периода одновременной работы двух версий (то есть как "антиканареечный" деплой)

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

Мне кажется перед использованием Helm, все таки надо ручками попробовать все в тестовой среде, чтобы понимать как изнутри все работает.

Является ли антипаттерном один большой самописный helm-чарт, в котором описаны десятки и сотни (микро)сервисов одной большой системы или нужно стремиться к схеме "один сервис — один чарт" без каких-либо "зонтичных" чартов?

Возможны варианты, в зависимости от задачи. Но разбиение на некие логические фрагменты целесообразно, проще дебажить.

Логические и так есть, по сервисам. Каждый сервис в своей папочке

Да, это антипаттерн. Надо использовать сабчарты.
Но, вообще, у вас не очень понятен вопрос. Сначала вы сказали, что один большой чарт на все, а потом сказали, что у вас зонтичный чарт (тогда он зонтичный, а не один большой).

Я не говорил что у меня :) Но вообще было тогда что-то непонятное:
один чарт на всю систему в папке charts которого лежат чарты по сервисам. Не архивы, а полностью, отдельно как зависимости не устанавливались, собственно dependencies вроде и не было в Chart.yaml. Всё это в одном репозитории, использовался как таковой только корневой

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