Helm, kustomize и GitOps
Вопрос
Как вы будете описывать и деплоить приложения в Kubernetes: Helm, kustomize, GitOps? Обоснуй выбор.
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Helm: шаблоны и параметры, удобен для переиспользуемых чартов и сторонних приложений, есть релизы и откаты
kustomize: наложения без шаблонов поверх обычных YAML, встроен в kubectl, проще читать
Часто сочетают: сторонние компоненты Helm-чартами, свои сервисы kustomize или общий внутренний чарт
GitOps (Argo CD, Flux): желаемое состояние в git, кластер синхронизируется сам, видны расхождения
Секреты не в values и не в git в открытом виде: SOPS или External Secrets
Проверки в CI: `helm template`/`kustomize build`, валидация схем, политики, diff перед применением
Что могут спросить следом
- Чем опасны ручные
kubectl editпри GitOps? - Как откатываться при GitOps?
Разбор
Для сторонних компонентов, ingress-контроллера, cert-manager, мониторинга, беру официальные Helm-чарты: у них есть параметры и релизы с откатом. Для своих сервисов выбор зависит от их числа. Если сервисов много и они похожи, удобен общий внутренний чарт, где каждый сервис только задаёт values. Если сервисов немного, kustomize проще: обычные YAML и наложения для окружений, без шаблонизатора, который со временем превращается в код на Go template. Доставку делаю через GitOps, Argo CD или Flux: в git лежит желаемое состояние для каждого окружения, контроллер в кластере применяет его и показывает расхождения, а откат это revert коммита. Ручные правки в кластере контроллер перезапишет, и это хорошо. Секретов в values и git нет: SOPS или External Secrets. В CI рендерю манифесты, прогоняю валидацию схем и политик и показываю diff в merge request, чтобы ревьюер видел, что реально изменится.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.