DevOps
GitOps: ArgoCD и Flux
2019 год: инженер крупного банка случайно запустил `kubectl delete namespace production` на боевом кластере. Восстановление заняло 4 часа, потому что никто не знал точное состояние инфраструктуры перед инцидентом. С GitOps восстановление заняло бы: `git log`, `argocd app sync` - минуты вместо часов.
- **Intuit** перевела 4000+ микросервисов на ArgoCD - каждый деплой в production требует PR-апрув, полная история всех изменений хранится в Git с именем инженера и причиной изменения.
- **Weaveworks** (авторы термина GitOps) использовали Flux для обновления firmware на промышленных IoT устройствах - тот же reconciliation loop, что и для Kubernetes, но для edge-узлов.
- **CERN** использует Flux для управления тысячами кластеров экспериментального оборудования - любое изменение конфигурации детекторов проходит code review в Git.
Декларативная модель: Git как единый источник истины
В 2017 году команда Weaveworks сформулировала термин GitOps: все желаемое состояние инфраструктуры хранится в Git-репозитории, а автоматический агент непрерывно приводит реальное состояние кластера в соответствие с репозиторием. Не `kubectl apply` руками - а система, которая сама следит за соответствием.
**4 принципа GitOps (OpenGitOps):** (1) Декларативность - желаемое состояние описано, не проскриптовано. (2) Версионированность - весь манифест в Git с историей и откатом. (3) Автоматическое применение - одобренные изменения применяются автоматически. (4) Непрерывная верификация - система постоянно проверяет соответствие. **Разница с traditional CI/CD:** традиционный пайплайн pushes в кластер; GitOps агент pulls из Git - кластер никогда не доступен напрямую из CI.
В чем ключевое архитектурное отличие GitOps от традиционного CI/CD с точки зрения безопасности?
Reconciliation Loop: непрерывная синхронизация
Reconciliation - сердце GitOps. ArgoCD и Flux непрерывно сравнивают желаемое состояние (Git) с реальным (кластер) и применяют разницу. Это не одноразовый деплой - это бесконечный цикл коррекции, работающий каждые несколько минут.
**Reconciliation в ArgoCD:** каждые 3 минуты (или по webhook) ArgoCD сравнивает Live State (реальные Kubernetes объекты) с Desired State (Git). Разница = diff. При `selfHeal: true` разница применяется автоматически. **Flux reconciliation:** GitRepository controller проверяет Git, Kustomization/HelmRelease controller применяет изменения. Каждый controller независим. **Что сравнивается:** не только spec ресурсов, но и labels, annotations. Поле `managedFields` помогает отследить что управляется GitOps.
Оператор вручную изменил `replicas: 3` в деплойменте через `kubectl edit` (в Git указано `replicas: 2`). ArgoCD с `selfHeal: true`. Что произойдет?
Drift Detection: обнаружение отклонений
Configuration drift - когда реальное состояние инфраструктуры постепенно расходится с задокументированным. В традиционных командах это накапливается годами: 'мы изменили это вручную на проде три года назад и забыли'. GitOps решает проблему на уровне системы: любое расхождение немедленно видно как Sync Status = OutOfSync.
**ArgoCD Sync Status:** Synced - кластер совпадает с Git. OutOfSync - есть расхождение (diff). Unknown - не удалось проверить. **Health Status:** Healthy, Degraded, Progressing, Suspended. **Что вызывает drift:** ручные изменения через kubectl, изменения контроллерами (HPA меняет replicas), изменения при rollback через kubectl rollout. **Инструменты:** `argocd app diff my-app` показывает точный diff; ArgoCD UI подсвечивает расхождения визуально.
HPA (Horizontal Pod Autoscaler) постоянно изменяет `spec.replicas` в Deployment. ArgoCD видит это как OutOfSync и возвращает 3 реплики из Git. Как решить?
Promotion: продвижение изменений между средами
GitOps меняет не только деплой, но и способ продвижения изменений между staging и production. Вместо 'запустить пайплайн с параметром ENV=prod' - создание Pull Request из staging-ветки в prod-ветку. Code review превращается в deployment review. Rollback - это git revert.
**Promotion стратегии:** (1) Branch-based: `main` -> `staging`, `release` -> `prod`. ArgoCD слушает разные ветки. (2) Directory-based: `clusters/staging/` и `clusters/prod/` в одном репозитории. Promotion - PR с копированием изменений. (3) Kustomize overlays: `base/` с общими манифестами, `overlays/staging/` и `overlays/prod/` с патчами. (4) Argo CD ApplicationSet: автоматически создает Application для каждой среды по шаблону. **Image promotion:** Flux Image Automation автоматически обновляет тег Docker образа в Git при появлении нового образа в registry.
GitOps подходит только для Kubernetes и контейнеров
GitOps - паттерн управления инфраструктурой через Git как источник истины, применимый к любой IaC системе: Terraform, Ansible, Crossplane, serverless конфигурациям.
Flux имеет провайдеры для Terraform (tf-controller), AWS, Azure. Принцип reconciliation loop применим к любой системе, поддерживающей декларативное описание состояния.
Команда использует GitOps с ArgoCD. Нужно срочно откатить production деплой. Правильный GitOps-способ?
Ключевые идеи
- **GitOps pull-модель** устраняет необходимость предоставлять CI-серверу доступ к кластеру - агент сам тянет желаемое состояние из Git.
- **Reconciliation loop** непрерывно сравнивает Git с кластером и автоматически исправляет расхождения - ручные изменения через kubectl откатываются при selfHeal.
- **Rollback в GitOps** = `git revert` - история сохранена, изменение задокументировано, ArgoCD/Flux применяют автоматически.
Связанные темы
GitOps строится поверх CI/CD пайплайнов и IaC-инструментов:
- CI/CD пайплайны — CI строит образы и обновляет теги в Git; GitOps агент применяет изменения в кластер
- Terraform: основы IaC — GitOps принципы применяются и к Terraform через tf-controller или Atlantis
Вопросы для размышления
- Как организовать secrets management в GitOps если секреты нельзя хранить в Git?
- В каких сценариях автоматическое selfHeal может быть опасным и стоит его отключить?
- Как GitOps меняет процесс incident response по сравнению с традиционным kubectl-подходом?