Argo CD (GitOps deployment)

核心 · Key Idea

In one line: Argo CD watches K8s manifests (raw YAML / Helm / Kustomize) in a git repo and continuously syncs them to the cluster. git push = deployed; manual cluster edits are detected / auto-reverted — the declarative GitOps model.

What it is#

# An Application is itself just YAML
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/me/infra
    path: apps/web
    targetRevision: main
    helm:
      valueFiles: [values-prod.yaml]
  destination:
    server: https://kubernetes.default.svc
    namespace: prod
  syncPolicy:
    automated: { prune: true, selfHeal: true }
    syncOptions: ["CreateNamespace=true"]

git push to update values → Argo CD syncs to the cluster within seconds.

Analogy#

打个比方 · Analogy

Without Argo CD = deploys are going to the cluster with a hammer — manual kubectl, results vary. With Argo CD = a built-in robot in the cluster watches the git repo and reshuffles state to match.

Key concepts#

ApplicationApplication

A set of K8s resources + source git path + target cluster/namespace.

AppProjectAppProject

Group of Applications + RBAC + allowed source repos / target clusters.

Sync policySync Policy

manual / automated; automated splits into prune (drop resources missing from git) and selfHeal (revert manual changes).

DriftDrift

Cluster diverges from git. Argo flags it as OutOfSync.

HookSync hooks

PreSync / PostSync / SyncFail — for migrations, notifications, etc.

ApplicationSetDynamic application generation

Generators (Git / List / Cluster) declare many Applications at once.

Argo RolloutsProgressive delivery

Companion project — Canary / Blue-Green / traffic split, replaces Deployment.

Workflow#

Practical notes#

GitOps golden rule: the cluster is read-only. All changes go via git → CI → ArgoCD apply.
Suggested structure: one repo for platform (CRDs / cluster-level), one for apps; or monorepo with directory isolation.
Helm + Kustomize both supported — for complex setups use helmfile / helm-include / kustomize, whichever fits.
App of Apps: one Application referencing many — a root manifest bootstrapping the whole cluster.
Multi-cluster: one ArgoCD instance can drive many target clusters (different destination.server secrets).
Approvals / windows: ApplicationSet + sync windows to gate production deploy times.
Secrets: sealed-secrets / external-secrets / SOPS — only ciphertext in git.
Rollback: argocd app rollback web or simply git revert.

Easy confusions#

Argo CD (GitOps)

Cluster pulls, **git is always the source of truth**.
Auto drift detection + self-healing.

GitHub Actions deploy step

Pipeline pushes, **event-driven**.
One-shot, no state-conservation notion.