In this lesson, you will learn how to shift from manual helm install commands to a declarative GitOps model where your cluster continuously synchronizes its state with a Git repository using tools like Argo CD.
The GitOps Paradigm Shift
Traditionally, you might use a CI/CD pipeline to push Helm charts to your cluster. However, "push" models often suffer from configuration drift—where manual kubectl tweaks make your cluster state diverge from your Git repo.
GitOps controllers (like Argo CD) operate on a pull basis. Instead of a CI tool deploying to the cluster, a controller running inside your cluster monitors your Git repository. When it detects a change in your values.yaml or Helm chart version, it automatically pulls those changes and reconciles the cluster to match the defined source of truth.
Declaring the Sync with Application CRDs
To automate this, we define an Application custom resource. This CRD tells the controller exactly where your Helm chart lives and what parameters to apply.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: my-web-app
spec:
project: default
source:
repoURL: 'https://github.com/org/charts.git'
targetRevision: HEAD
path: charts/web-app
helm:
values: |
replicaCount: 3
destination:
server: 'https://kubernetes.default.svc'
namespace: production
When you commit a change to the values block in Git, the controller detects the difference between the live cluster and the Git state. It then executes the helm template internally and applies the resulting manifests. If someone manually deletes a resource or changes a setting, the controller will detect the deviation and automatically "self-heal" by reverting the cluster back to the state defined in Git. This ensures that your deployment process is auditable, repeatable, and resilient against accidental drift.
Key Takeaway: By using GitOps controllers, you transform Helm deployments into a continuous reconciliation loop, ensuring your Kubernetes environment always matches your version-controlled infrastructure definitions.