Phase 3: CI/CD & Automation

ArgoCD / Flux Continuous Reconciliation

Intermediate ~2 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you’re building a super cool, giant LEGO castle. It’s got thousands of pieces, towers, bridges, and even tiny flagpoles. To make sure you build it exactly right, you use a detailed instruction book. This book shows every single brick and where it goes. Now, what if you had a special robot helper who loved checking your work?

This robot helper's job is called "continuous reconciliation." It constantly looks at your actual LEGO castle and compares it, piece by piece, with the official instruction book. It wants to make sure your real-life castle is always exactly what the book says it should be. If you accidentally move a brick, or maybe your little brother takes off a roof piece without telling you – that's a "drift." The robot immediately notices this drift because the real castle doesn't match the book anymore.

As soon as the robot sees a drift, it doesn't wait for you to fix it. It springs into action! It gently picks up the misplaced brick and puts it back exactly where the instruction book says it belongs. It might even put the roof back on if it was missing. The robot's goal is to always, always make sure your physical castle matches the perfect plan in the instruction book. And it does this check all the time, over and over.

So, when grown-up engineers are building huge software systems, they use a "master plan" (like your LEGO instruction book) that tells all the computers exactly what programs to run and how to set them up. This "continuous reconciliation" is like our robot helper for computers. It constantly checks that the real-world computer systems perfectly match the master plan. This means engineers can trust that if they update the plan, the computers will automatically become exactly what the plan describes. This makes building and maintaining really big, complicated computer programs much easier and more reliable, because you know everything will always be exactly as it should be.

Continuous reconciliation is the core engine of GitOps with tools like ArgoCD and Flux. At its heart, it's the constant, automated process that ensures your Kubernetes cluster's actual state always matches the desired state defined in your Git repository. Think of it as an ever-vigilant watchdog: it perpetually compares what should be running (as specified in Git) with what is running in your cluster. If it detects any discrepancy, known as "drift" – perhaps due to a manual change made directly to the cluster or an external factor – it springs into action to correct it, bringing the cluster back into alignment with the Git source of truth.

Practically, this reconciliation loop operates by regularly fetching the latest configuration from your designated Git repository (either by polling at intervals or reacting to webhooks). It then renders these configurations (e.g., Helm charts, Kustomize overlays) into concrete Kubernetes manifests. The tool then compares these rendered manifests against the live resources in your cluster. If a difference is found – maybe a deployment's replica count was manually scaled up, or a ConfigMap was edited directly – the GitOps agent will re-apply the correct configuration from Git. This ensures that any out-of-band changes are ephemeral and your cluster truly reflects the version-controlled state.

This continuous process is what gives GitOps its powerful self-healing and auditable characteristics. With proper configuration (e.g., syncPolicy: automated in ArgoCD), your applications can automatically recover from unexpected changes or even misconfigurations, as the desired state from Git is persistently enforced. It removes the need for manual intervention to correct environmental inconsistencies, drastically improving operational consistency and reliability for your infrastructure and applications.

Key Takeaways

  • Continuously compares Git (desired state) with cluster (actual state).
  • Automatically detects and corrects "drift" (discrepancies).
  • Ensures Git remains the single source of truth for your infrastructure.
  • Provides self-healing capabilities by enforcing desired state.
  • Improves operational consistency and reliability.

Code Example

yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-webapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/my-org/kubernetes-configs.git
    targetRevision: HEAD
    path: apps/my-webapp
  destination:
    server: https://kubernetes.default.svc
    namespace: my-webapp-prod
  syncPolicy:
    automated:
      prune: true # Delete resources that are no longer in Git
      selfHeal: true # Automatically sync when drift is detected
    syncOptions:
      - CreateNamespace=true # Create target namespace if it doesn't exist

How this code works

This ArgoCD Application code defines how a specific application, my-webapp, should be deployed and continuously managed in a Kubernetes cluster, following GitOps principles. It instructs ArgoCD to monitor a Git repository for the desired state of my-webapp and ensure the cluster always matches that state.

The source section points ArgoCD to https://github.com/my-org/kubernetes-configs.git, specifically to the apps/my-webapp directory on the HEAD (latest) revision. This is where ArgoCD finds the Kubernetes manifests for my-webapp. The destination then specifies where these resources should be applied: to the https://kubernetes.default.svc cluster, within the my-webapp-prod namespace. A key part of GitOps is the syncPolicy, which has automated syncing. prune: true ensures that resources removed from Git are also deleted from the cluster, keeping it clean. Crucially, selfHeal: true means ArgoCD will automatically revert any manual changes made directly in the cluster that deviate from the Git state, enforcing continuous reconciliation. The CreateNamespace=true syncOption conveniently ensures the my-webapp-prod namespace is created if it doesn't already exist.

Related Articles

Hand-picked reads to go deeper on gitops (argocd / flux).

Back to DevOps Engineer Roadmap