GitOps (Хранение состояния в Git)

GitOps — это подход к управлению инфраструктурой и приложениями, при котором все изменения проходят через Git. Репозиторий становится единственным и достоверным источником конфигурации: всё, что должно быть в кластере — описано в коде и хранится в Git.

Вместо ручных операций или запуска команд из CI-системы, GitOps предполагает, что изменения сначала фиксируются в Git (обычно через pull request), а затем автоматически применяются в Kubernetes-кластере с помощью специального контроллера.

Ключевые принципы GitOps:

Git как источник правды — любая инфраструктурная или приложенческая конфигурация живёт в Git.
Pull request — как точка входа для изменений. Через него проходит ревью, тестирование, и только потом — доставка.
Автоматическая синхронизация — система GitOps сравнивает текущее состояние кластера с тем, что в репозитории, и при необходимости применяет обновления.
Обратимость — любое изменение можно откатить простым git revert, и система сама вернёт кластер в нужное состояние.

Инструменты GitOps:

Argo CD — настраиваемый GitOps-контроллер для Kubernetes, умеет синхронизировать манифесты и следить за дрифтом состояния.
Flux — лёгкий и гибкий GitOps-движок, интегрируемый с GitHub, GitLab и другими.
GitHub Actions / GitLab CI — часто используются в связке с Argo CD или Flux для запуска пайплайнов и валидации изменений.

GitOps сильно упрощает:

отслеживание истории и аудит (всё зафиксировано в коммитах),
автоматизацию релизов без ручных операций,
управление средами (dev, staging, prod — всё из одного репозитория),
катастрофоустойчивость (кластер можно «восстановить из Git»).

GitOps vs DevOps: GitOps — это узкоспециализированный подход внутри DevOps-культуры. Если DevOps охватывает процессы, автоматизацию, взаимодействие команд, то GitOps — это конкретная реализация доставки и управления через Git.

Сегодня GitOps активно используется в компаниях, где важны стабильность, прозрачность и повторяемость процессов — особенно в связке с Kubernetes и микросервисной архитектурой.

GitOps Flow: от коммита до обновления кластера (на примере Argo CD)

Разработчик делает изменение в манифесте
- В Git-репозитории есть структура с YAML-файлами (Deployment, Service, Ingress и др.).
- Изменения оформляются как Pull Request (PR) в нужную ветку (например, main или staging).
PR проходит ревью и попадает в main
- После мержа Argo CD начинает отслеживать изменения. Он знает, к какому кластеру и в каком namespace относится этот каталог манифестов.
Argo CD сравнивает текущее состояние кластера с Git
- Контроллер запрашивает актуальные ресурсы в Kubernetes и сверяет их с тем, что написано в Git.
- Если найдено расхождение — состояние считается OutOfSync.
Синхронизация
- Argo CD автоматически (или вручную, по триггеру) применяет нужные манифесты, чтобы привести кластер в соответствие с Git.
- Это делается с помощью стандартных kubectl apply-операций под капотом.
Кластер обновлён
- Новый образ, обновлённая конфигурация или изменённая структура вступает в силу.
- В интерфейсе Argo CD можно отслеживать историю, статусы и логи.

Пример Argo CD Application манифеста (CRD)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  source:
    repoURL: https://github.com/my-org/k8s-manifests
    targetRevision: main
    path: apps/my-app
  project: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Что делает этот манифест:

Подключает каталог apps/my-app из репозитория;
Следит за веткой main;
Разворачивает всё в namespace production;
Включает автоматическую синхронизацию с selfHeal (автовосстановление) и prune (удаление лишнего).

Было полезно?