Helm и GitOps
Helm-чарты и шаблонизация, учёт релизов и откат, Helm против Kustomize, pull-модель GitOps и согласование дрейфа в ArgoCD.
8 вопросов
JuniorТеорияЧастоЧто такое GitOps и что означает pull-модель согласования?
Что такое GitOps и что означает pull-модель согласования?
GitOps делает Git единственным источником истины для желаемого состояния. Контроллер внутри кластера непрерывно тянет репо и согласует кластер. Pull-модель значит, что агент изнутри применяет изменения, а не push-CI снаружи с kubectl apply — так доступ к кластеру не покидает доверенную зону.
Типичные ошибки
- ✗Считать GitOps-ом CI, запускающий
kubectl apply(push CD) - ✗Верить, что Git хранит живое состояние кластера, а не желаемое
- ✗Упускать, что pull-агент избавляет от раздачи учётных данных кластера
Уточняющие вопросы
- →Почему pull-агент безопаснее, чем push-деплой из CI?
- →Что является единственным источником истины в GitOps и почему?
JuniorТеорияЧастоЧто такое Helm и какую проблему решают чарты при развёртывании в Kubernetes?
Что такое Helm и какую проблему решают чарты при развёртывании в Kubernetes?
Helm — это менеджер пакетов для Kubernetes. Чарт упаковывает шаблонизированные манифесты и values.yaml со значениями по умолчанию, так что параметризованный пакет ставится в разные окружения. Это убирает копипаст почти одинакового YAML, а helm install ведёт это как версионируемый релиз.
Типичные ошибки
- ✗Думать, что Helm собирает или доставляет образы, а не пакует манифесты
- ✗Считать чарт статичным YAML без шаблонизации и values
- ✗Путать пакетирование Helm с непрерывным согласованием у GitOps-контроллера
Уточняющие вопросы
- →Что делает
helm upgradeиз того, чего не делает свежийhelm install? - →Почему шаблонизация чарта безопаснее, чем копия манифеста на каждое окружение?
JuniorТеорияИногдаИз каких основных частей состоит Helm-чарт — Chart.yaml, values.yaml и templates/?
Из каких основных частей состоит Helm-чарт — Chart.yaml, values.yaml и templates/?
Chart.yaml — это метаданные чарта: имя, версия и зависимости. values.yaml хранит конфигурацию по умолчанию, переопределяемую при установке. templates/ содержит манифесты на Go-шаблонах, которые Helm рендерит, подставляя туда values, а charts/ вендорит зависимые сабчарты.
Типичные ошибки
- ✗Путать
Chart.yaml(метаданные) сvalues.yaml(конфиг по умолчанию) - ✗Думать, что
templates/хранит готовые манифесты, а не шаблонный исходник - ✗Не знать, что зависимости чарта объявляются в
Chart.yaml
Уточняющие вопросы
- →Как переопределить значение в
values.yaml, не редактируя сам чарт? - →Где лежит собственный
values.yamlсабчарта относительно родительского?
JuniorТеорияИногдаКак Helm отслеживает релизы и как откатить релиз к предыдущей версии?
Как Helm отслеживает релизы и как откатить релиз к предыдущей версии?
Каждый helm install/upgrade создаёт нумерованную ревизию релиза, и Helm хранит отрендеренные манифесты каждой ревизии (в Secret). helm history показывает их; helm rollback применяет сохранённую ревизию как новую, накатывая старое состояние, не стирая историю.
Типичные ошибки
- ✗Думать, что
helm rollbackстирает новые ревизии, а не добавляет одну - ✗Считать, что Helm не хранит историю и откат требует ручной переустановки
- ✗Не знать, что отрендеренные манифесты хранятся по ревизиям в кластере
Уточняющие вопросы
- →Где Helm 3 хранит состояние релиза и чем это отличается от Helm 2?
- →Что происходит с нумерацией
helm historyсразу послеhelm rollback?
MiddleДебаггингИногдаGitOps-контроллер Argo CD откатывает ручной хотфикс — диагностируйте
GitOps-контроллер Argo CD откатывает ручной хотфикс — диагностируйте
Это Argo CD работает как задумано, а не баг. В Git стоит replicas: 2, поэтому ручной kubectl edit — это дрейф, и self-heal откатывает его к состоянию из Git; правка кластера не закрепится под auto-sync. Чините в Git: закоммитьте replicas: 6 и дайте Argo CD синхронизироваться.
Типичные ошибки
- ✗Считать откат дрейфа через self-heal багом Argo CD
- ✗Чинить желаемое состояние правкой кластера, а не Git
- ✗Отключать self-heal как фикс вместо коммита изменения в Git
Уточняющие вопросы
- →Когда временно отключить self-heal оправдано и в чём риск этого?
- →Как сделать экстренный скейл-ап устойчивым через сам GitOps-процесс?
MiddleТеорияИногдаКак GitOps-контроллер Argo CD обнаруживает и устраняет дрейф от Git?
Как GitOps-контроллер Argo CD обнаруживает и устраняет дрейф от Git?
Argo CD хранит желаемое состояние из Git и постоянно сверяет его с живым кластером. При расхождении оно помечается OutOfSync, а синхронизация применяет Git-состояние. С auto-sync и self-heal изменение мимо Git откатывается, и ручной kubectl edit отменяется — источник истины Git.
Типичные ошибки
- ✗Думать, что Argo CD пишет живое состояние кластера обратно в Git
- ✗Считать, что согласование срабатывает только по Git-webhook, а не постоянно
- ✗Ждать, что ручной
kubectl editпереживёт auto-sync с self-heal
Уточняющие вопросы
- →С включённым self-heal почему ручной
kubectl editпродолжает откатываться? - →Чем
OutOfSyncотличается от здоровьяDegradedв Argo CD?
MiddleКодИногдаОтрендерите значение чарта со значением по умолчанию в Helm-шаблоне
Отрендерите значение чарта со значением по умолчанию в Helm-шаблоне
Используйте функцию Helm default: {{ .Values.image.tag | default .Chart.AppVersion }}. Она подставляет .Values.image.tag, когда он задан, и откатывается к appVersion чарта, если он пуст или не задан. Чарт ставится без единого override, но пользователь всё ещё может закрепить тег.
Типичные ошибки
- ✗Подавать аргументы в
defaultв неверном порядке, переворачивая приоритет - ✗Использовать
required, который обрывает рендер, а не откатывается к дефолту - ✗Считать, что в Go-шаблонах есть тернарник
?:для значения по умолчанию
Уточняющие вопросы
- →Как, наоборот, сделать значение обязательным, чтобы рендер падал, если оно не задано?
- →Что вернёт
default, когда.Values.image.tag— пустая строка против nil?
SeniorТеорияИногдаПакетный Helm против оверлейного Kustomize — компромиссы на масштабе?
Пакетный Helm против оверлейного Kustomize — компромиссы на масштабе?
Helm — менеджер пакетов: Go-шаблоны, values.yaml, зависимости чартов и версионируемые релизы с откатом ценой сложности шаблонов. Kustomize делает оверлеи без шаблонов — база плюс патчи чистого YAML на окружение, но без пакетирования, версий и жизненного цикла релиза. На масштабе оба сочетают: Kustomize патчит, Helm распространяет.
Типичные ошибки
- ✗Звать Kustomize шаблонизатором, а не инструментом оверлеев/патчей
- ✗Думать, что у Kustomize есть релизы и откат, как у Helm
- ✗Верить, что Helm не может менять конфиг на окружение через
values.yaml
Уточняющие вопросы
- →Почему оверлеи Kustomize бывает легче ревьюить в git-diff, чем шаблоны Helm?
- →Как команды сочетают Helm и Kustomize в одном пайплайне доставки?
