GitOps with ArgoCD

GitOps with ArgoCD

Master the pulse of the cluster. Learn how to use ArgoCD to implement GitOps, ensuring your cluster stays in sync with your Git repository and automatically heals itself if something drifts.

GitOps with ArgoCD: The Self-Healing Cluster

In the previous lesson, we built a CI/CD pipeline where GitHub Actions "Pushes" changes to the cluster. This is great, but it has a weakness: Configuration Drift.

If a developer manually runs kubectl edit deployment to fix a bug in the middle of the night, your GitHub Action doesn't know. The "Live" state of the cluster is now different from the YAML in your Git repo. This is how "Ghost Bugs" and unrepeatable environments are born.

To solve this, we move to GitOps. In a GitOps model, we don't "Push" to the cluster. Instead, we install an agent inside the cluster called ArgoCD. ArgoCD pulls the code from Git and says: "I see that Git says I should have 5 replicas, but currently there are only 3. I will fix that right now."

In this lesson, we will master the GitOps principles, learn to install and configure ArgoCD, and understand how "Automatic Syncing" can make your AI infrastructure 100% predictable and self-healing.


1. What is GitOps? (The Three Laws)

  1. Declarative Manifests: Everything is defined as code (YAML/Helm).
  2. Git as Source of Truth: What is in Git is what is in production. Period.
  3. Automated Reconciliation: An agent (ArgoCD) constantly compares Git to Live and fixes any differences.

2. Introducing ArgoCD

ArgoCD is a declarative, GitOps continuous delivery tool for Kubernetes. It runs as a set of deployments in your cluster.

The Lifecycle:

  1. Poll: ArgoCD watches your Git repository every 3 minutes.
  2. Diff: It compares the YAML in Git with the YAML running in K8s.
  3. Sync: If there is a difference, it "Applies" the Git version.
  4. Health: It monitors the health of the resulting pods and shows a "Green" status in its UI.

3. Defining an ArgoCD Application

To tell ArgoCD to manage your app, you create an Application resource.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: ai-agent-prod
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/my-org/ai-repo.git'
    targetRevision: HEAD
    path: charts/ai-agent # Path to your Helm chart
    helm:
      valueFiles:
        - values-prod.yaml
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: production
  syncPolicy:
    automated: # TRIGGER MAGIC
      prune: true # Delete objects that were removed from Git
      selfHeal: true # Overwrite manual changes (kubectl edit) immediately

4. Visualizing the GitOps Loop

graph LR
    Dev["Developer"] -- "Git Commit / PR" --> Git["GitHub Repo"]
    
    subgraph "Kubernetes Cluster"
        Argo["ArgoCD Controller"] -- "Pull / Watch" --> Git
        Argo -- "State Comparison" --> K8s["Live K8s State"]
        
        K8s -- "Drift Detected!" --> Argo
        Argo -- "Auto-Reconcile (Apply)" --> K8s
    end
    
    style Argo fill:#f96,stroke:#333
    style Git fill:#9cf,stroke:#333

5. Pruning and Self-Healing: The Safety Nets

Self-Healing

If a hacker gains access and deletes your deployment, ArgoCD will see the deletion within seconds and Re-create it instantly from Git. This is a massive security win.

Pruning

If you delete a YAML file from Git, ArgoCD will Delete it from the cluster. This ensures your cluster doesn't become a "Junkyard" of old, unused resources.


6. Practical Example: The "Preview Environment"

When an AI engineer opens a Pull Request with a new model configuration, you want to see it running before you merge it.

The GitOps Strategy:

  1. Your CI pipeline creates a temporary Git branch.
  2. The CI environment creates a "Temporary" ArgoCD Application pointing to that branch.
  3. ArgoCD spins up the "Preview" cluster.
  4. Once the PR is merged, the CI deletes the Application, and ArgoCD Prunes the preview pods.

7. AI Implementation: Version-Locked Deployments

In AI, you often have a "Stable" version of your agent and a "Canary" version.

The GitOps Way:

In your Git repo, you have two folders:

  • /clusters/production/stable -> Points to helm-chart:v1.0
  • /clusters/production/canary -> Points to helm-chart:v1.1

ArgoCD manages BOTH as separate applications. When you are happy with the Canary, you simply update the "Stable" folder in Git to point to v1.1, and ArgoCD handles the promotion across your entire worldwide cluster.


8. Summary and Key Takeaways

  • GitOps: The modern gold standard for K8s deployment.
  • ArgoCD: The "Reconciliation Loop" that lives inside your cluster.
  • Source of Truth: Git is the law; avoid manual kubectl changes in production.
  • Self-Healing: Automatic recovery from accidental or malicious deletions.
  • Observability: The ArgoCD UI provides a clearer visual map of your application resources than kubectl.

In the final lesson of this module, we will look at how we safely transition users between these versions using Canary and Blue-Green Deployments.


9. SEO Metadata & Keywords

Focus Keywords: Kubernetes GitOps tutorial ArgoCD, installing ArgoCD K8s guide, ArgoCD self-healing vs pruning, Git as source of truth Kubernetes, pull-based vs push-based deployment K8s, GitOps for AI infrastructure.

Meta Description: Take the human out of the loop. Learn how to implement GitOps with ArgoCD to create a self-healing Kubernetes cluster that is always in sync with your Git repository, ensuring stability and security for your production AI and web services.

Subscribe to our newsletter

Get the latest posts delivered right to your inbox.

Subscribe on LinkedIn