Master GitOps with Argo CD for robust Kubernetes CD. Learn how to implement declarative infrastructure and automate your deployments with this step-by-step guide.
I’ve spent years chasing "drift" in production clusters. You know the drill: someone runs a kubectl edit to fix a memory limit, forgets to update the Helm chart, and three weeks later, a redeployment wipes out the fix. It's a nightmare. That's why I moved my teams to GitOps.
Using Argo CD for Kubernetes CD transforms your repository into the single source of truth. When your infrastructure is declarative, the cluster state is just a reflection of your Git repo. If it's not in Git, it doesn't exist.
In a traditional CI/CD pipeline, the CI server (like Jenkins or GitHub Actions) pushes changes to the cluster. This requires the CI server to hold cluster-admin credentials. That’s a security risk.
Argo CD flips this. It runs inside your cluster as a controller. It pulls the desired state from Git and reconciles it with the live environment. If someone manually changes a service type, Argo CD detects the drift and—depending on your policy—reverts it automatically.
Before we dive into the YAML, make sure you have:
kubectl installedI prefer installing via the official manifests. It’s straightforward and keeps the control plane isolated.
Bashkubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.8.4/manifests/install.yaml
Once the pods are running, you’ll need to expose the server. For local testing, port-forwarding works, but for production, use an Ingress controller like Nginx or Istio.
Bashkubectl port-forward svc/argocd-server -n argocd 8080:443
Log in with the default admin password, which is the name of the initial server pod:
Bashkubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2
Don't just point Argo CD at a raw directory. Structure your repo to separate your application code from your deployment manifests. I typically use a base and overlays pattern with Kustomize.
Here’s a basic Application manifest that tells Argo CD where to look:
YAMLapiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-app namespace: argocd spec: project: default source: repoURL: 'https://github.com/my-org/my-app-manifests.git' targetRevision: HEAD path: overlays/production destination: server: 'https://kubernetes.default.svc' namespace: my-app-prod syncPolicy: automated: prune: true selfHeal: true
The selfHeal: true flag is the magic piece. It ensures that if the live state drifts from Git, Argo CD forces the cluster to match the repository.
You might wonder where your CI pipeline fits in. Your CI pipeline should build the Docker image, push it to your registry, and then—crucially—update the image tag in the Git repository.
Don't let the CI pipeline talk to Kubernetes. Let the CI pipeline talk to Git. This creates an audit log of every change, who made it, and exactly what version is deployed.
selfHeal temporarily during maintenance windows to avoid unnecessary churn.Once you’ve implemented this, your workflow changes. You stop SSHing into nodes or running kubectl commands. Instead, you submit a Pull Request. Once approved and merged, Argo CD handles the heavy lifting of rolling out the change.
It’s cleaner, it’s auditable, and most importantly, it’s repeatable. When a cluster dies, you don't panic. You just point a new cluster at your Git repository, and Argo CD reconstructs your entire production environment in minutes.
That’s the power of Declarative Infrastructure. Stop managing servers; start managing state.
Master GitOps with Argo CD and Crossplane to manage infrastructure as code. Learn how to unify your Kubernetes deployment strategy for apps and cloud resources.
Read moreLearn to implement Kubernetes Policy as Code using Crossplane and OPA Gatekeeper. Secure your infrastructure with automated guardrails in a GitOps workflow.