Платформенная команда обсуждает переход с текущей модели (CI-пайплайн выполняет helm upgrade/kubectl apply при каждом merge) на GitOps-модель, где Flux или ArgoCD в кластере сами непрерывно приводят состояние кластера в соответствие с Git-репозиторием манифестов/чартов. Какие архитектурные различия и последствия для drift-reconciliation и безопасности нужно обсудить при выборе между этими подходами, и почему нельзя просто сказать, что GitOps однозначно лучше?

Короткий ответ

В пайплайн-модели CI имеет прямой push-доступ к кластеру и применяет изменения только в момент деплоя, то есть drift между деплоями не исправляется автоматически; в GitOps-модели pull-агент (Flux/ArgoCD) внутри кластера постоянно сверяет текущее состояние с Git и самостоятельно выполняет reconciliation, включая откат ручных изменений кем-то через kubectl, что даёт более сильную гарантию соответствия Git состоянию кластера, но требует, чтобы агент имел широкие права внутри кластера на изменение ресурсов, и смещает вопрос безопасности с "кто может запускать deploy pipeline" на "кто может мержить в Git-репозиторий манифестов" и "насколько защищён сам GitOps-агент".

Как это работает подробнее

при push-модели секреты для доступа к кластеру должны быть у CI-системы (внешней по отношению к кластеру), что создаёт риск утечки учётных данных кластера через CI; при pull-модели агент работает внутри кластера с учётными данными, не покидающими его, но сам агент становится высокопривилегированной целью атаки, и компрометация репозитория манифестов (а не только CI) становится прямым путём к изменению продакшена, поэтому для GitOps особенно критичен code review и защита веток в самом Git.

Сравнение

• Компромисс. GitOps даёт более сильную гарантию соответствия Git и снижает риск несанкционированного push-доступа к кластеру, но требует зрелого процесса защиты самого Git-репозитория манифестов (review, защищённые ветки, подписанные коммиты) и обучения команды его поведению при инцидентах; пайплайн-модель проще для команд, привыкших к push-деплоям, и даёт более предсказуемое поведение во время ручных hotfix, но не устраняет drift автоматически и требует доверенного доступа CI к кластеру. Выбор зависит от зрелости команды в работе с Git-процессами и от того, насколько критичен автоматический откат неучтённых ручных изменений именно для этой организации.

Пример кода

playbook.ymlКопировать

# пример ArgoCD Application: продолжает синхронизировать кластер с Git непрерывно,
# в том числе откатывая ручные изменения, не зафиксированные в Git
apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  source:
    repoURL: https://git.acme.local/infra/manifests.git
    path: apps/web
  syncPolicy:
    automated:
      selfHeal: true   # именно этот флаг откатывает ручной kubectl-дрифт
      prune: true

Что использовать на практике

• Практика. непрерывный reconciliation в GitOps означает, что ручные экстренные изменения через kubectl (hotfix во время инцидента) будут автоматически откатаны агентом при следующей синхронизации, если их не внести также в Git — это дисциплинирует процесс, но может застать команду врасплох во время инцидента, если она не знает об этом поведении и ожидаемо использует kubectl edit как при push-модели.

Подводные камни

• Ошибка. Не выполняйте изменение без проверки плана, резервной копии состояния и понятного способа отката; для production согласуйте окно работ и исключите параллельные операции.