Argo CD GitOps: From Git to the Cluster

Enterprise problem: Ziba’s GKE infrastructure can be reproducible while the live Deployment still drifts after emergency kubectl edits, and a push-based pipeline with broad cluster credentials can deploy an unreviewed image or silently leave production different from Git. Whole-course context: Terraform mapped reviewed configuration and state to GCP resources; today consumes an existing reachable cluster and moves Kubernetes application delivery into a continuous GitOps reconciliation loop. Today’s slice: Argo CD compares Git target state with Kubernetes live state, reports drift, and optionally syncs Ziba under bounded policy; Terraform continues to own the VPC, GKE cluster, node pools, and Argo CD installation boundary. End-of-day evidence: A reviewer sees commit-to-sync provenance, health, served image digest, a detected drift, a denied unauthorized change, and recovery. Still unsolved: Multi-cluster promotion, secret delivery, disaster recovery, progressive traffic shifting, and production auto-sync approval remain environment decisions.

GitOps is not merely deploying from Git; it must continuously expose whether the approved revision and live application differ. These use cases cover intended release and out-of-band drift recovery.

Sync status alone can be green while an application is unhealthy, so acceptance must include both configuration convergence and customer behavior. These stories retain positive and negative evidence across Git, Argo CD, Kubernetes, and the request path.

Continuous reconciliation can also continuously apply a bad decision, so the flow separates review, comparison, policy, sync, and health. The recovery path preserves drift evidence before correcting it.

Argo CD owns application reconciliation, not the servers beneath the cluster. Its repository server renders manifests, while the application controller continuously compares live Kubernetes resources with the target in Git and can take corrective action (Argo CD architecture).

Git, Argo CD status, and Kubernetes live objects cannot be one authority because each records a different part of the control loop. Ziba’s content database, if any, remains outside declarative manifest reconciliation and needs its own backup and migration lifecycle.

Generated-application database: Not created in this slice — Git revisions, Argo CD Application state/history, Kubernetes resources, audit events, and HTTP probes provide the durable deployment evidence required here.

The phrase “Git is the source of truth” is incomplete unless a controller repeatedly compares it with live state and reports what happened. Expand the three boxes into render, compare, policy, apply, observe, and repeat.

Automatic sync can act when target and live state differ, but pruning and self-healing are separate choices; automatic pruning is off by default, and self-heal must be explicitly enabled (Argo CD automated sync policy). Treat each as a deletion or mutation authority decision, not a convenience checkbox.

A GitOps controller cannot infer ownership from a directory name, so the Application must bind source, destination, and policy explicitly. Keep the workload manifest in the referenced path and pin production images by digest.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: ziba-prod
  namespace: argocd
spec:
  project: ziba-production
  source:
    repoURL: https://github.com/example/ziba-deployments.git
    targetRevision: main
    path: environments/production
  destination:
    server: https://kubernetes.default.svc
    namespace: blog
  syncPolicy:
    automated:
      enabled: true
      prune: false
      selfHeal: true
    syncOptions:
      - CreateNamespace=false

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ziba
  namespace: blog
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ziba
  template:
    metadata:
      labels:
        app: ziba
    spec:
      containers:
        - name: blog
          image: europe-west2-docker.pkg.dev/ziba-prod/blog/site@sha256:REPLACE_ME
          readinessProbe:
            httpGet:
              path: /healthz
              port: 3000

Treating Terraform and Argo CD as substitutes creates overlapping ownership and control loops. Give each resource exactly one primary reconciler, and connect them through explicit outputs and bootstrap dependencies.

A Git commit changes no running bytes until reconciliation is authorised and Kubernetes controllers act. This table separates source, control-plane, software, hardware, and customer consequences.

A screenshot of a green Argo CD application cannot prove the served revision or the negative path. Capture machine-readable status, Kubernetes rollout, customer response, then introduce a safe staging drift and preserve the OutOfSync diff before recovery.

argocd app get ziba-prod -o json
argocd app diff ziba-prod
argocd app sync ziba-prod
argocd app wait ziba-prod --sync --health --timeout 300
kubectl -n blog rollout status deployment/ziba
kubectl -n blog get deployment ziba -o jsonpath='{.spec.template.spec.containers[0].image}{"\n"}'
curl --fail --show-error "${ZIBA_URL}/healthz"

For the staging-only drift exercise, change a harmless annotation with an authorised emergency identity, capture the audit event and OutOfSync diff, then choose self-heal or a reviewed Git adoption. Also prove that an unapproved identity receives a Kubernetes RBAC denial. Never induce production drift merely to satisfy a course exercise.

An OutOfSync status is a comparison result, not a diagnosis, and Healthy is not proof that the intended revision is live. Use both signals plus rollout and request evidence.

GitOps closes a control loop between reviewed target state and live Kubernetes objects. Argo CD supplies that application loop; it does not replace the infrastructure, identity, data, or customer-health layers around it.

• Git records target state; Argo CD renders, compares, syncs, and observes; Kubernetes controllers run the workload.
• Synced and Healthy answer different questions, and neither alone proves the customer response.
• Auto-sync, self-heal, and prune grant different mutation/deletion authorities.
• Terraform and Argo CD complement each other when their resource ownership is disjoint.
• Drift must produce evidence and a decision, not silent correction without attribution.

A GitOps release is complete only when provenance, convergence, health, and denial are all observable. Retain the evidence under the same release identifier.

• [ ] Application binds an allowlisted repository/path/revision to an allowlisted cluster/namespace
• [ ] Production image is digest-pinned and manifests pass pre-merge validation
• [ ] Auto-sync, self-heal, prune, and allow-empty are separately reviewed
• [ ] Argo CD and Terraform ownership tables contain no overlapping resource fields
• [ ] Captured commit, diff, operation ID, resource UIDs, health, image digest, HTTP result, time, and environment
• [ ] Proved safe staging drift recovery and unauthorised Kubernetes mutation denial