WeDoOps

🚨 Когда Argo CD не синхронизирует состояние

Развернули приложение через Argo CD — всё зелёное, синхронизация прошла. Через час заходите — статус OutOfSync. Репозиторий вроде не трогали, но кластер считает иначе.

Или другая классика: разработчик пушит изменения, Argo CD их видит, но деплой встаёт. Оказывается, коллега втихаря сделал kubectl apply, и теперь реальное состояние кластера разошлось с Git.

🤔 Главная проблема — потерянный источник истины
В GitOps истина живёт только в Git-репозитории. Любое изменение в обход Git создаёт рассинхрон. Argo CD честно сигнализирует об этом, но сам не знает, что делать, если мы не настроили правила.

🛠 Решение — грамотная syncPolicy
У каждого приложения можно чётко определить, как именно выполнять синхронизацию. Три ключевых параметра:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: false        # не удаляем ресурсы, которых нет в Git
      selfHeal: true      # автооткат к состоянию из Git при любом дрифте
    syncOptions:
    - CreateNamespace=true

🔹 selfHeal: true — главный защитник от «ручных правок». Если кто-то меняет ресурс через kubectl edit, Argo CD сам вернёт всё к тому, что описано в Git. Без этого флага приложение навсегда останется OutOfSync.

🔹 prune: false — безопасный старт. Мы запрещаем удалять из кластера объекты, которых нет в репозитории. Защита от случайной потери данных. На prune: true переходим только когда на 100% уверены в чистоте манифестов.

🔹 CreateNamespace=true — мелочь, а приятно: Argo CD сам создаст нужный namespace, не придётся делать это руками.

😎 Масштабируем подход: App-of-Apps
Для больших проектов используют паттерн «приложение приложений»: одно root-приложение управляет дочерними. Важно: корневой манифест должен разворачиваться строго в неймспейс, где живёт контроллер Argo CD (обычно argocd), иначе дочерние приложения не распознаются.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-of-apps
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/infra.git
    targetRevision: HEAD
    path: apps/
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd   # обязательно сюда
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Каждое дочернее приложение описывается своим YAML-файлом и может иметь уникальные политики. Например, для баз данных оставляем prune: false, а для легковесного фронтенда включаем prune: true.

🔄 Бонус: очерёдность через Sync Waves
Если нужно сначала поднять базу, а потом бэкенд, используйте аннотацию синхронизации:

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"

Ресурсы с меньшей волной (хоть -5) применяются и проверяются на готовность раньше остальных.

51 views17:55