GitOps: Управление инфраструктурой и Kubernetes с Git как единым источником истины

1. Определение GitOps: За рамками традиционных CI/CD конвейеров

В современной cloud-native разработке термин GitOps часто ошибочно путают с простой автоматизацией CI/CD или хранением Bash-скриптов в репозитории Git. Запуск команды kubectl apply или terraform apply из сборочного раннера GitHub Actions или GitLab CI при слиянии коммита — это push-автоматизация развертывания, а не GitOps.

GitOps, согласно стандартам рабочей группы OpenGitOps (CNCF), базируется на четырёх фундаментальных принципах:

1. Декларативное описание: Все состояние инфраструктуры, сеть, манифесты приложений и политики безопасности описываются декларативно.
2. Версионированное и неизменяемое хранилище: Git выступает единственным источником истины (SSOT). Каждое изменение криптографически подписано и сохраняет полную историю версий.
3. Автоматическое извлечение (Pull-based): Внутрикластерный агент синхронизации (Reconciliation agent) непрерывно опрашивает Git и применяет манифесты напрямую изнутри кластера, не требуя внешних учетных данных администратора.
4. Непрерывный цикл согласования и устранение дрейфа конфигурации (Drift Detection): Агент постоянно сравнивает фактическое состояние кластера (Actual State) с желаемым состоянием из Git (Desired State) и автоматически устраняет несанкционированные ручные изменения.

+-------------------------------------------------------------------------+
|                           Рабочее место инженера                        |
|  git commit -m "feat: scale catalog replicas" && git push               |
+-----------------------------------+-------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                  Репозиторий Git (Единый источник истины: SSOT)         |
|  - manifests/base/catalog.yaml                                          |
|  - overlays/production/kustomization.yaml                              |
+-----------------------------------+-------------------------------------+
                                    |
          Цикл синхронизации        | Git Poll / Webhook (Pull-модель)
          Внутрикластерный агент    v
+-------------------------------------------------------------------------+
|                  Кластер Kubernetes / Управляющий контур                |
|                                                                         |
|  +---------------------+        Сравнение       +---------------------+ |
|  |  GitOps-контроллер  | -------------------->  | Фактическое         | |
|  |  (Argo CD / Flux)   | <--------------------  | состояние (Kube API)| |
|  +---------------------+      Поиск дрейфа      +---------------------+ |
|             |                                             ^             |
|             +-------- Автосинхронизация / Self-Heal ------+             |
+-------------------------------------------------------------------------+

Архитектурные различия: Push против Pull

• Push-модель: Внешний сервер CI хранит долговременные ключи администратора (kubeconfig). При взломе CI злоумышленник получает полный контроль над кластером. Ручные правки (kubectl edit) не отслеживаются вплоть до следующего пуша.
• Pull-модель: Учетные данные никогда не покидают периметр кластера. Внутренний контроллер читает Git по безопасному протоколу. Любой дрейф конфигурации немедленно перезаписывается каноническим состоянием из Git.

2. Управление окружениями с помощью Kustomize

Паттерн Base/Overlay позволяет гибко переопределять конфигурации для staging и production без дублирования кода:

# apps/ecommerce-service/overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../../base

namespace: ecommerce-production

images:
  - name: ghcr.io/ladestack/ecommerce-service
    newTag: v2.14.0

patches:
  - target:
      kind: Deployment
      name: ecommerce-service
    patch: |-
      - op: replace
        path: /spec/replicas
        value: 12

3. Сравнение платформ: Argo CD и Flux CD

• Argo CD: Отличается мощным веб-интерфейсом, корпоративной интеграцией SSO и управлением проектами с разграничением прав (RBAC). Оптимален для платформ самообслуживания разработчиков.
• Flux CD: Модульная архитектура в стиле Unix без встроенного интерфейса. Максимально нативен для Kubernetes, потребляет минимум ресурсов и идеально подходит для edge-кластеров.

4. Безопасность секретов и риски отката

• Секреты: Хранение открытых паролей в Git запрещено. Используются решения Sealed Secrets (асимметричное шифрование перед коммитом) или External Secrets Operator (интеграция с Vault, AWS/GCP KMS).
• Откат (Rollback): Команда git revert не способна откатить деструктивные изменения в схемах баз данных. Требуется внедрение шаблона Expand-Contract для обеспечения полной обратной совместимости.