GitOps with ArgoCD and Flux: Declarative Kubernetes

GitOps: Git as the Source of Truth

GitOps applies DevOps best practices to infrastructure and deployment. The core idea: Git repositories contain the complete desired state of your system. Automated agents continuously reconcile actual state with desired state.

No more kubectl apply from laptops. No more wondering what is actually deployed. Git history becomes your audit log, and pull requests become your change management process.

The Four Principles

Declarative: Describe what you want, not how to get there. Kubernetes manifests, Terraform configs, Helm charts - all declarative descriptions of desired state.

Versioned and immutable: All changes go through Git. Every change is tracked, attributed, and reversible. Roll back by reverting a commit.

Pulled automatically: Agents in the cluster pull changes from Git, rather than CI pushing to clusters. More secure - clusters need read access to Git, not the other way around.

Continuously reconciled: Agents constantly compare actual state to desired state. Drift is automatically corrected. Manual changes are overwritten.

ArgoCD vs Flux

Both are excellent GitOps operators. Choose based on your needs:

ArgoCD: Rich UI for visualizing deployments, application health, and sync status. Better for teams that want visibility and manual controls. Supports multiple clusters from one instance.

Flux: Lighter weight, more composable. Toolkit approach lets you use only what you need. Better for teams that prefer CLI and automation over UI. Native Helm and Kustomize support.

Many teams start with ArgoCD for its UI, then consider Flux for more complex multi-cluster scenarios.

Repository Strategies

Mono-repo: All manifests in one repository. Simpler to manage, atomic changes across services. Can become unwieldy at scale.

Repo per app: Each application owns its deployment manifests. Clear ownership, independent lifecycles. More repositories to manage.

Config repo separate from app repo: Application code in one repo, Kubernetes manifests in another. CI updates the config repo on successful builds. Clean separation but more coordination needed.

Handling Secrets

GitOps means everything in Git - but secrets cannot be plaintext. Options:

Sealed Secrets: Encrypt secrets with a cluster-specific key. Only the cluster can decrypt.

SOPS: Mozilla's encryption tool. Encrypt secret values while keeping structure readable.

External Secrets Operator: Reference secrets in external stores (Vault, AWS Secrets Manager). GitOps manages the references, not the secrets themselves.

Progressive Delivery Integration

GitOps and progressive delivery complement each other. Flagger or Argo Rollouts manage canary deployments while ArgoCD or Flux handle the underlying GitOps workflow.

Change the desired state in Git, let the GitOps operator apply it, let the progressive delivery controller manage the rollout safely.

Best Practices

Separate config and code repos: Cleaner CI/CD, clearer ownership

Use Kustomize or Helm: Manage environment differences

Protect main branch: PRs with reviews for all changes

Monitor sync status: Alert on drift or failed syncs

Encrypt secrets: Never plaintext in Git

Start simple: One cluster, one repo, then expand