Использовать helm чарты с различным окружением и версионированием . Тот же самый темплейтинг на основе env-окружения и т.д. Неспорю, что подобную конструкцию можно нагородить из баша, гавна и палок, но тут все в одном бинарнике и одном ямл файле. удобно,просто и читабельно + портируется легко в другие среды.
kustomize
Rainbow
Andor
Использовать helm чарты с различным окружением и версионированием . Тот же самый темплейтинг на основе env-окружения и т.д. Неспорю, что подобную конструкцию можно нагородить из баша, гавна и палок, но тут все в одном бинарнике и одном ямл файле. удобно,просто и читабельно + портируется легко в другие среды.
Как будто других шаблонизаторов нету
Rainbow
Мне не нравился helm и в принципе все шаблонизаторы из-за того, что там есть IF, if зло. Я за линейный деплой
Andrey
в итоге приходится жить с helm
Andor
Выйдет хельм3 с шаьлонами структур, а не текста - тогда хельм будет норм :)
Andrey
+
Denis
kustomize
Или ksonet. Я не говорю конкретно что хелм хороший и пушистый. Я вообщем говорю про семейство подобных иструментов, которые решают задачи по упрощению CI CD в k8s
Andor
он довольно урезанный по сравнению с helm и многих задач просто не решит
Какие задачи ты решаешь хельмом, кроме рендеринга шаблонов кубе манифестов?
Rainbow
helm никак не упрощает cicd. Что apply, что helm одна команда
Rainbow
Походу никто не согласен, что if это зло 😑
Andrey
Какие задачи ты решаешь хельмом, кроме рендеринга шаблонов кубе манифестов?
пример:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
{{range $i, $e := until (atoi (printf "%d" (int64 .Values.replicaCount))) }}
- node-{{$i|add1}}.com
{{end}}
Andor
Или ты не конкретно про параметризацию, а про логикк в шаблонах?
Andrey
логика
Отделение Bereke Bank
helm никак не упрощает cicd. Что apply, что helm одна команда
Но ведь в хелм можно задать порядок создания объектов. Например сначала миграции а потом деплой
Andor
пример:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
{{range $i, $e := until (atoi (printf "%d" (int64 .Values.replicaCount))) }}
- node-{{$i|add1}}.com
{{end}}
Ты уверен что это ответ на мой вопрос?
Andrey
это пример реализации того что тот же kustomize не умеет. helm кроме рендинга у меня и деплоит через helm upgrade —install
Andor
Но ведь в хелм можно задать порядок создания объектов. Например сначала миграции а потом деплой
А ты уверен, что это задача шаблонизатора, а не шедулера?
Rainbow
пример:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
{{range $i, $e := until (atoi (printf "%d" (int64 .Values.replicaCount))) }}
- node-{{$i|add1}}.com
{{end}}
вместо дополнительных label сделали цикл, бомба.
Rainbow
if/range зло.
Отделение Bereke Bank
А ты уверен, что это задача шаблонизатора, а не шедулера?
Я просто не смог такое сделать сам а в хелм это пара строк 🤔
Rainbow
Но ведь в хелм можно задать порядок создания объектов. Например сначала миграции а потом деплой
миграция это шаг в CI перед deploy
buld -> migrate -> deploy
все просто
Andrey
Я лично опять упоролся и решил попробовать перевести один из наших сервисов с хелма на оператор.
Andor
Andor
Никогда не было
Rainbow
Вешаешь метки на ноды и ставишь аффинити по этим меткам
я так тоже подумал, но
{range $i, $e := until (atoi (printf "%d" (int64 .Values.replicaCount))) }}
сильно похоже на daemonset
Andor
Ты не на то сообщение ответил :)
Andrey
Вешаешь метки на ноды и ставишь аффинити по этим меткам
есть stetfulset и нужно задать четкий порядок разворачивания подов по нодам. Чем метки отличаются от хостов, кроме как дополнительно еще какие то метки вешать?
Andrey
Рассказывай
Дело идёт неплохо, но то, что нельзя через апи удобно создать джобу и дождаться ее выполнения дико злит пушо хочется перед обновлением деплойментов прогнать миграции. А так уже все работает, решу эту проблему и будет уже шаблон для последующих сервисов.
Rainbow
есть stetfulset и нужно задать четкий порядок разворачивания подов по нодам. Чем метки отличаются от хостов, кроме как дополнительно еще какие то метки вешать?
тем, что не нужно делать range в шаблонизаторе
Rainbow
Andor
Rainbow
Миграции в ci это же так просто... ну блин
Andrey
оператор да, решит. без оператора - пример выше и он рабочий :)
Andrey
это просто как пример, что kustomize тот же не умеет
Andor
есть stetfulset и нужно задать четкий порядок разворачивания подов по нодам. Чем метки отличаются от хостов, кроме как дополнительно еще какие то метки вешать?
Что с порядком запуска если половина подов стейтфулсета помрёт?
Andrey
Миграции в ci это же так просто... ну блин
Но так неинтересно. Хочу чтоб херак два ямл файла и усе
Rainbow
пример:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
{{range $i, $e := until (atoi (printf "%d" (int64 .Values.replicaCount))) }}
- node-{{$i|add1}}.com
{{end}}
Чем это отличается от
nodeSelector:
mylabel: myvalue
?
Andrey
Что с порядком запуска если половина подов стейтфулсета помрёт?
да хоть все помирайте, главное по очереди по нодам запустить)
Rainbow
Но так неинтересно. Хочу чтоб херак два ямл файла и усе
В смысле? А .gitlab-ci.yaml вам чем не yaml?
Andrey
и вы не поняли сути примера :)
Andrey
В смысле? А .gitlab-ci.yaml вам чем не yaml?
У меня Дженкинс и я имел ввиду исключительно ресурсы кубеней
Andor
да хоть все помирайте, главное по очереди по нодам запустить)
Ноды померли и потом вернулись - в каком порядке запустятся?
Rainbow
У меня Дженкинс и я имел ввиду исключительно ресурсы кубеней
да, я больше иронизировал. Просто море граблей вместо миграции из ci это печально. Второй вопрос после "как поставить куб" и все начинают, helm, wait-for, initContainers и тп. Просто шаг ci и все 🙈
Rainbow
и вы не поняли сути примера :)
ну мне лень было писать affinity. У вас метка host и N значений. Можно свою метку, одно значение и накинуть на ноды N меток. Странности, что количество нод зависат от реплик - странности. Кто гарантирует, что ноды не поселятся....
Rainbow
А....
Rainbow
Или вы делали что-то вроде
helm upgrade —set replicas=1
helm upgrade —set replicas=2
helm upgrade —set replicas=3
???
Andrey
да, я больше иронизировал. Просто море граблей вместо миграции из ci это печально. Второй вопрос после "как поставить куб" и все начинают, helm, wait-for, initContainers и тп. Просто шаг ci и все 🙈
Так-то звучит неплохо, но хочу я запилить кубеня-нейтив решение и все тут
Andrey
Ноды померли и потом вернулись - в каком порядке запустятся?
requiredDuringSchedulingIgnoredDuringExecution
Andrey
Andrey
У меня почти все так развёрнуто. Хорошо отслеживается история в гит, даже для deps. Все сведено к
cat k8s.yaml | envsubst | kubectl apply -f -
ну вот уже не совсем голый apply. А откаты? А секреты?
Rainbow
ну вот уже не совсем голый apply. А откаты? А секреты?
откат - запуск прошлого pipeline
секреты да, kustomize это может, а там где чистой apply у меня нет особо секретов. Если у вас в команде 5 человек из которых 1.5 имеют доступ в кубер секреты не особо нужны так то.
Andrey
то есть откат вручную?
Andor
Ну CD может это детектить
Andor
Но это на стороне CD решается, конкретный шаблонизатор неважен
Andrey
а у вас как-то автоматически обнаруживается карявая выкатка?
с хелмом? да. helm upgrade --wait || helm rollback
Andrey
Но это на стороне CD решается, конкретный шаблонизатор неважен
не только лишь все CD умеют такое
Andor
с хелмом? да. helm upgrade --wait || helm rollback
То есть условие "выкатка прошла успешно" выносится хельмом, а не автотестами?
Rainbow
То есть условие "выкатка прошла успешно" выносится хельмом, а не автотестами?
это проблема прогеров. прогеры козлы сделали корявую выкатку.
Andrey
То есть условие "выкатка прошла успешно" выносится хельмом, а не автотестами?
а смысл запускать автотесты, если они будут стучатся в старые поды, которые deployment держит, пока новые не поднялись?
Andor
А смысл держать старые поды если ты не можешь проверить, работают ли новые?
Andrey
helm может
Andor
Всякие гринблю и прочие канарейки для этого же придумывали
Andor
helm может
Хельм может запустить автотесты и исходя из их результата откатывать или убивать старые репликасеты?
Andrey
ну вот deployment с readinessprobe это такое poor man green/blue
Andor
А если нет желания быть poor?
Andor
Ты же потом всё равно после рединес проб запустишь автотесты
Andrey
Хельм может запустить автотесты и исходя из их результата откатывать или убивать старые репликасеты?
нет. Он может ждать когда deployment обновится
Andor
И если они зафейлят - всё равно откатывать
Andor
"деплоймент обновился" - недосаточное условие чтобы решать, успешно выкатилась новая версия или нет
Andrey
Я же про преимущества helm над apply говорю
Andor
тогда apply тоже не подойдёт
Он точно так же подойдёт, не хуже и не лучше, потому что логика в ci/cd, а не в шаблонизаторе