Внедрение GitOps-подхода для управления инфраструктурой

Мы внедряем GitOps как операционную модель, где git-репозиторий становится единым источником правды для состояния инфраструктуры и приложений. Любое изменение в кластере — через Pull Request. Никаких kubectl apply руками. Никаких terraform apply с локальной машины разработчика. Это звучит просто, но переход от «мы деплоим через CI» к настоящему GitOps-подходу затрагивает процессы, архитектуру репозиториев, управление секретами и культуру команды.

Почему GitOps требует планомерного подхода?

Самая частая ошибка — установить ArgoCD или Flux, настроить синхронизацию одного приложения и объявить «у нас GitOps». Через месяц выясняется: часть ресурсов по-прежнему создаётся вручную через kubectl create namespace, секреты хранятся в CI-переменных и применяются в pipeline, Helm values для production редактируются напрямую в кластере без commit в git. Drift между тем, что в репозитории, и тем, что реально крутится — накапливается незаметно.

Вторая проблема: монолитный репозиторий без чёткой структуры. Когда apps/ перемешан с infrastructure/, а overlays/ для разных окружений не консистентны — onboarding нового инженера превращается в детектив. Kustomize overlays и Helm values нужно организовывать по окружениям (base/, overlays/dev/, overlays/prod/) с самого начала, а не рефакторить потом.

Управление секретами в GitOps — отдельная головная боль. В git нельзя хранить plaintext secrets. Три рабочих варианта: Sealed Secrets (шифрование через kubeseal, секрет расшифровывается только контроллером в кластере), SOPS с age/GPG (зашифрованные файлы в git, расшифровка в runtime), External Secrets Operator (секреты живут в Vault/AWS SSM/GCP Secret Manager, ESO синхронизирует их как Kubernetes Secrets). Выбор зависит от того, есть ли уже Vault в инфраструктуре и нужен ли единый secrets store для нескольких кластеров.

Как выбрать GitOps-оператор: ArgoCD vs Flux?

Для большинства команд ArgoCD удобен при необходимости визуализации и многокластерного управления. Flux выбирают проекты, где всё должно работать через pipeline без ручного вмешательства.

Архитектура GitOps-внедрения

Полноценное внедрение включает несколько слоёв:

Репозиторная стратегия. Два основных паттерна: monorepo (всё в одном репозитории — инфраструктура + приложения) и polyrepo (отдельный app repo + отдельный gitops/config repo). Для большинства команд оптимален вариант App repo отдельно, GitOps config repo отдельно — это разделяет жизненные циклы кода и конфигурации, убирает конфликты при одновременной работе нескольких команд.

Структура config репозитория под Kustomize:

gitops-config/
├── apps/
│   ├── base/
│   │   └── myapp/
│   │       ├── deployment.yaml
│   │       ├── service.yaml
│   │       └── kustomization.yaml
│   └── overlays/
│       ├── dev/
│       │   └── kustomization.yaml # patch ресурсов + replica=1
│       └── prod/
│           └── kustomization.yaml # patch ресурсов + HPA + PDB
├── infrastructure/
│   ├── cert-manager/
│   ├── ingress-nginx/
│   └── monitoring/
└── clusters/
    ├── dev/
    └── prod/

Выбор GitOps-оператора. ArgoCD — более богатый UI, удобен для мультикластера, ApplicationSet для генерации приложений из шаблонов. Flux v2 — более cloud-native, лучше интегрируется с Helm OCI-репозиториями, подходит для автоматизированных workflows без UI. На практике ArgoCD чаще выбирают команды, которым важна визуализация, Flux — там, где всё через GitOps pipeline без ручного вмешательства.

CI/CD интеграция. В GitOps CI остаётся за сборкой и тестированием. CD полностью уходит в GitOps-оператор. CI pipeline строится по схеме: build → test → push image → update image tag in config repo → ArgoCD/Flux подхватывает изменение и синхронизирует кластер. Обновление тега в config repo можно делать через kustomize edit set image или через Argo CD Image Updater / Flux Image Automation.

Пример GitHub Actions step для обновления image tag в config repo:

- name: Update image tag in gitops repo
  run: |
    git clone https://github.com/org/gitops-config.git
    cd gitops-config
    kustomize edit set image myapp=registry.example.com/myapp:${{ github.sha }}
    git add .
    git commit -m "ci: update myapp to ${{ github.sha }}"
    git push
  working-directory: apps/overlays/dev

Drift Detection и Self-healing

Одно из главных преимуществ GitOps — автоматическое восстановление после ручных изменений в кластере. Если кто-то изменил replicas напрямую через kubectl scale, ArgoCD обнаружит расхождение и через настроенный sync interval (по умолчанию 3 минуты) вернёт состояние к тому, что в git. Это называется self-healing, и оно должно быть включено осознанно — не для всех ресурсов сразу.

Ресурсы, которые часто нужно исключить из auto-sync: HPA (horizontal pod autoscaler меняет replicas автоматически, конфликт с GitOps-синхронизацией), PersistentVolumeClaims (изменение может привести к потере данных), некоторые CRD с dynamic reconciliation. В ArgoCD это настраивается через ignoreDifferences:

spec: ignoreDifferences: - group: apps kind: Deployment jsonPointers: - /spec/replicas 

Этапы внедрения

Внедрение GitOps — это итеративный процесс, не единоразовая задача.

Полный цикл от аудита до production-ready GitOps — от 3 недель для небольшого стека до 3 месяцев при сложной мультикластерной инфраструктуре с compliance-требованиями.

Что входит в работу

• Аудит текущей инфраструктуры и deploy-процессов
• Проектирование репозиторной структуры (monorepo или polyrepo)
• Настройка GitOps-оператора (ArgoCD или Flux) с RBAC и multi-tenancy
• Поэтапная миграция приложений с сохранением работоспособности
• Внедрение управления секретами (Sealed Secrets/SOPS/External Secrets Operator)
• Разработка документации и runbook
• Обучение команды и поддержка на этапе запуска

Свяжитесь с нами для аудита вашей инфраструктуры — мы оценим объём работ и сроки внедрения. Опыт нашей команды — более 5 лет успешных проектов по GitOps-трансформации в компаниях разного масштаба. Гарантируем результат: сокращение времени деплоя на 30-50% и исключение ручных операций.

Получите консультацию по выбору GitOps-оператора и архитектуре репозиториев.