GitOps и ArgoCD
Кластер сам подтягивает состояние из git — и что это меняет по сравнению с деплоем «пайплайн пушит в прод».
Идея в одном предложении
GitOps — это когда желаемое состояние инфраструктуры описано в git, а специальный контроллер постоянно приводит реальность к этому описанию.
Классический пайплайн работает наоборот: CI собирает образ и сам пушит изменения в кластер (kubectl apply, helm upgrade). Это push-модель. В GitOps кластер сам тянет изменения из репозитория — pull-модель.
Что это меняет
| Push (CI деплоит) | Pull (GitOps) | |
|---|---|---|
| Кто имеет доступ в кластер | CI-система с правами на запись | Только контроллер внутри кластера |
| Что в проде | То, что задеплоил последний пайплайн | То, что в git — всегда |
| Откат | Перезапуск старого пайплайна | git revert |
| Ручные правки в кластере | Живут незамеченными | Контроллер видит расхождение (drift) |
Последняя строка — главная. Ручной kubectl edit в push-модели остаётся навсегда и о нём забывают; GitOps-контроллер такое расхождение подсвечивает или сразу затирает обратно.
ArgoCD
Самый распространённый GitOps-контроллер для Kubernetes. Единица работы — Application: ссылка на репозиторий + путь к манифестам + целевой кластер и namespace.
Цикл ArgoCD:
- читает манифесты из git (helm, kustomize или голый YAML);
- сравнивает с тем, что реально в кластере;
- показывает diff и статус —
Synced/OutOfSync; - приводит кластер к git — по кнопке или автоматически (auto-sync).
Деплой новой версии при этом — просто коммит, меняющий тег образа в манифесте. Кто, что и когда менял — видно в git log, аудит бесплатно.
Когда это оверкилл
Один сервис на одном сервере с docker compose не становится лучше от ArgoCD — там достаточно git pull && docker compose up -d по SSH. GitOps окупается, когда кластеров и сервисов много, деплоят несколько команд и вопрос «а что сейчас в проде?» перестаёт иметь очевидный ответ.