Своими словами объясните принцип GitOps: что является источником истины и как изменения попадают в кластер?

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

В GitOps единственным источником истины для желаемого состояния окружения является Git-репозиторий с декларативными манифестами; специальный контроллер (например, ArgoCD или Flux) постоянно сверяет реальное состояние кластера с репозиторием и автоматически приводит его в соответствие.

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

инженер меняет YAML-манифест (например, версию образа) в Git и открывает pull request; после мерджа GitOps-контроллер, работающий внутри кластера, замечает изменение и сам применяет его через Kubernetes API — не требуется, чтобы внешняя CI-система «пушила» изменения в кластер.

Пример кода

example.yamlКопировать

# apps/myapp/deployment.yaml в Git-репозитории
spec:
  template:
    spec:
      containers:
        - name: myapp
          image: registry.example.com/myapp:1.5.0

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

• На практике. такой pull-based подход снижает поверхность атаки (кластеру не нужно давать доступ внешним CI-раннерам) и даёт встроенный аудит через историю коммитов и автоматическое обнаружение дрифта — если кто-то вручную поменял ресурс через `kubectl edit`, контроллер со временем вернёт состояние к тому, что описано в Git.
• Пример. Ожидаемое поведение: после изменения тега на `1.6.0` и мерджа в main, ArgoCD в течение короткого времени (по умолчанию опрос каждые несколько минут, либо мгновенно через webhook) применяет новую версию в кластере, и статус приложения в ArgoCD UI меняется на `Synced`.

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

• Частые ошибки. путают GitOps с «просто хранением манифестов в Git» без автоматической синхронизации — без контроллера сверки это обычный declarative-деплой через CI, а не GitOps; считают, что GitOps исключает ручные изменения совсем, хотя на практике возможны временные ручные вмешательства, которые потом нужно синхронизировать обратно в Git.