βΆArgo CD vs Flux CD β which GitOps tool should I choose?
Argo CD: web UI, stronger visualization, larger community, steeper learning curve, better for teams new to GitOps. Flux CD: lightweight, YAML-native, Git-first philosophy, faster feedback loops, preferred by GitOps purists. For most enterprises: Argo CD. For minimal footprint clusters: Flux CD. Many teams run both for different workloads.
βΆWhat are sync waves and why do they matter?
Sync waves allow you to control the order of resource creation in ArgoCD. Example: create namespaces (wave 0), then RBAC (wave 1), then applications (wave 2). Prevents race conditions where a pod tries to start before its configmap exists. Critical for multi-tier applications and database migrations.
βΆHow do I manage multiple clusters with Argo CD?
Three patterns: (1) Single Argo CD instance + registered clusters (simple, hub-spoke), (2) Argo CD per cluster (decentralized, GitOps per team), (3) ApplicationSets with cluster wildcards (monorepo, dynamic cluster discovery). ApplicationSets + monorepo = current best practice for 10+ clusters.
βΆHow does Argo CD detect and fix drift in production?
Argo CD periodically compares Git state (desired) vs cluster state (actual). If drift detected: yellow/orange status. Auto-sync = instantly reconcile (dangerous). Manual sync = review changes first (safer). For production: manual sync + PR approval. For dev: auto-sync.
βΆDeclarative vs imperative β why is Argo CD declarative?
Declarative: you declare desired state in Git, Argo CD converges cluster to match. Imperative: you run kubectl commands. Declarative wins because: (1) Git history = audit trail, (2) anyone can review PRs before deploy, (3) disaster recovery is just 'git checkout', (4) teams don't fight over 'who deployed what'.
βΆArgo Rollouts vs Argo CD β when do I need both?
Argo CD handles deployment automation. Argo Rollouts handles progressive delivery strategies (canary, blue-green, A/B testing). Use Argo CD to deploy Argo Rollouts manifests. Use Argo Rollouts to shift traffic gradually (10%β25%β100%) and auto-rollback on errors. Together: safe, auditable, gradual rollouts.
βΆHow do I secure secrets in GitOps workflows?
Never store plaintext secrets in Git. Use: (1) Sealed Secrets (encrypts in Git, decrypts in cluster), (2) External Secrets Operator (fetch from Vault/AWS Secrets), (3) Sops (encrypt secrets.yaml, decrypt at apply time), (4) Argo Vault plugin. Sealed Secrets + Argo CD = encrypted Git history.