GitOps з Argo CD

Ви навчитеся будувати pull-based GitOps delivery з Argo CD, обмежувати джерела й destinations через AppProject, керувати sync policy та діагностувати drift і помилки reconciliation.

• desired, live і target state
• Application і AppProject
• automated sync, prune та selfHeal
• health, sync status і Conditions
• promotion через Git

Git зберігає reviewed desired state. Argo CD періодично рендерить target state, порівнює його з live state Kubernetes і синхронізує відмінності. CI публікує immutable artifact та пропонує зміну Git; in-cluster controller виконує deploy.

Synced означає збіг target і live manifests, Healthy — працездатність за health assessment. Застосунок може бути Synced, але Degraded, або OutOfSync, але Healthy. Обидва виміри перевіряють незалежно.

Application пов’язує repository/path/revision із destination cluster/namespace та sync policy. AppProject є security boundary: обмежує sourceRepos, destinations, допустимі kinds і project roles.

default AppProject спочатку дозволяє будь-які repositories, clusters і kinds, тому для multi-tenant production створюйте окремі проєкти з allowlist. Repository credentials і cluster credentials не мають бути в Application manifest.

automated.enabled вмикає автоматичну синхронізацію Git change. prune видаляє керовані ресурси, що зникли з Git. selfHeal виправляє зміни лише в live cluster навіть без нового commit. allowEmpty=false захищає від випадкового видалення всіх ресурсів.

Ручне scale буде відновлено лише за selfHeal=true. Prune розширює blast radius помилки Git, тому використовуйте approvals, protected branches, sync windows і PruneLast. Orphaned resources та finalizers потребують усвідомленої політики видалення.

PreSync hooks виконуються до звичайних ресурсів, Sync разом з основною фазою, PostSync після Healthy, SyncFail за помилки. Annotation argocd.argoproj.io/sync-wave задає порядок від меншого числа до більшого.

Hooks мають бути idempotent: self-heal і повторний sync можуть запустити їх знову. Selective sync не запускає hooks, не записується в history і не підтримує rollback, тому не використовуйте його як звичайний production deployment.

Promotion — зміна immutable image digest або chart revision в окремому environment overlay через merge request. Staging і production відстежують різні paths або repositories; один artifact просувається без rebuild.

В automated application rollback через UI/CLI несумісний з auto-sync: controller знову застосує Git. Коректний rollback — revert або новий commit desired state. Для database changes використовуйте expand/contract і перевірений roll-forward plan.

• Фіксуйте targetRevision на reviewed commit або tag у production
• Розділяйте application source і platform configuration
• Обмежуйте AppProject repositories, destinations і kinds
• Не використовуйте ignoreDifferences, доки не визначено власника поля
• Перевіряйте rendered manifests і policy до merge
• Захищайте repository credentials та використовуйте read-only deploy keys
• Налаштовуйте notifications, metrics, SLO і backup Argo CD configuration
• Використовуйте HA installation для production; навчальний install не HA

Установіть зафіксовану Argo CD v3.4.6 у локальний kind. --force-conflicts потрібний офіційному server-side install для володіння CRD fields; не переносьте цей прапорець на application manifests. HA bundle потребує щонайменше три Nodes.

kubectl create namespace argocd
kubectl apply -n argocd --server-side --force-conflicts -f https://raw.githubusercontent.com/argoproj/argo-cd/v3.4.6/manifests/install.yaml
kubectl wait deployment/argocd-server -n argocd --for=condition=Available --timeout=300s
kubectl wait deployment/argocd-repo-server -n argocd --for=condition=Available --timeout=300s
kubectl wait statefulset/argocd-application-controller -n argocd --for=jsonpath='{.status.readyReplicas}'=1 --timeout=300s
kubectl get pod -n argocd

Збережіть об’єкти як app-project.yaml і application.yaml. Навчальний застосунок використовує публічний офіційний repository; гілка master потрібна для drift-вправи. У production замініть її на reviewed commit/tag і власний repository.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: course
  namespace: argocd
spec:
  description: Restricted training project
  sourceRepos:
    - https://github.com/argoproj/argocd-example-apps.git
  destinations:
    - server: https://kubernetes.default.svc
      namespace: guestbook
  clusterResourceWhitelist: []
  namespaceResourceBlacklist:
    - group: rbac.authorization.k8s.io
      kind: Role
    - group: rbac.authorization.k8s.io
      kind: RoleBinding

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: course
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: master
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      enabled: true
      prune: true
      selfHeal: true
      allowEmpty: false
    syncOptions:
      - PrunePropagationPolicy=foreground
      - PruneLast=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 1m

kubectl create namespace guestbook
kubectl apply -f app-project.yaml
kubectl apply -f application.yaml
kubectl wait application/guestbook -n argocd --for=jsonpath='{.status.sync.status}'=Synced --timeout=180s
kubectl wait application/guestbook -n argocd --for=jsonpath='{.status.health.status}'=Healthy --timeout=180s
kubectl get application guestbook -n argocd -o jsonpath='{.status.sync.status}{" "}{.status.health.status}{" revision="}{.status.sync.revision}{"\n"}'
kubectl get deployment,service,pod -n guestbook -o wide
kubectl port-forward -n guestbook service/guestbook-ui 8080:80

Критерій: Application Synced і Healthy, status містить Git revision, guestbook Deployment Available, Service відповідає через port-forward. Port-forward запускається в окремому терміналі.

Змініть replicas напряму: selfHeal має повернути значення з Git. Потім задайте відсутню revision, прочитайте Application Conditions і repo-server logs, відновіть джерело та виконайте очищення.

kubectl scale deployment guestbook-ui -n guestbook --replicas=3
kubectl get application guestbook -n argocd -w
kubectl get deployment guestbook-ui -n guestbook
kubectl get application guestbook -n argocd -o jsonpath='{.status.operationState.syncResult.revision}{"\n"}'
kubectl patch application guestbook -n argocd --type=merge -p='{"spec":{"source":{"targetRevision":"refs/heads/does-not-exist"}}}'
kubectl get application guestbook -n argocd -o jsonpath='{range .status.conditions[*]}{.type}{": "}{.message}{"\n"}{end}'
kubectl logs deployment/argocd-repo-server -n argocd --tail=100
kubectl patch application guestbook -n argocd --type=merge -p='{"spec":{"source":{"targetRevision":"master"}}}'
kubectl wait application/guestbook -n argocd --for=jsonpath='{.status.sync.status}'=Synced --timeout=180s
kubectl delete application guestbook -n argocd
kubectl delete appproject course -n argocd
kubectl delete namespace guestbook

Спостерігайте переходи, а не лише фінальний стан. Якщо manual scale не відновився, перевірте automated.enabled, selfHeal, refresh і ownership ресурсу.

Основні класи: repository authentication/TLS, render error Helm/Kustomize, заборонений AppProject source або destination, Kubernetes RBAC/admission, apply conflict, failed hook і unhealthy workload.

argocd app get guestbook
argocd app diff guestbook
argocd app history guestbook
argocd app manifests guestbook
argocd app resources guestbook
kubectl get application guestbook -n argocd -o yaml
kubectl events -n argocd --for application/guestbook
kubectl logs statefulset/argocd-application-controller -n argocd --tail=200
kubectl logs deployment/argocd-repo-server -n argocd --tail=200

Ланцюжок: Application Conditions → sync/health → operationState → resource tree/diff → repo-server під час render → application-controller під час apply → Kubernetes Events і workload logs. Не натискайте Sync повторно без нової гіпотези.

• Чим Synced відрізняється від Healthy?
• Що окремо роблять automated, prune та selfHeal?
• Чому AppProject є security boundary?
• Чому manual scale відновлюється не завжди?
• Чому Git revert кращий за argocd rollback при auto-sync?
• Які ризики мають hooks і selective sync?
• Як просувати один digest між environments?

Модуль засвоєно, якщо ви декларативно створюєте обмежений проєкт і застосунок, спостерігаєте self-heal, діагностуєте ComparisonError і виконуєте promotion/rollback через Git.