Multi-Cluster & Where GitOps Picks Up

In one line

Real production setups often span more than one cluster, and manage all of them by treating a Git repository as the single source of truth — a genuine, distinct approach worth understanding conceptually, even before a dedicated GitOps course goes deep.

0/4 · 0%

Key ideas

01
A single cluster is a genuinely reasonable starting point, but real production setups often span MULTIPLE clusters — separate clusters per environment (dev/staging/production, mirroring Linux's own environment-variable discipline, now at the infrastructure level), per region (for latency and disaster recovery, echoing Linux's own high-availability concepts), or per team, each with its own genuinely separate blast radius if something goes wrong.
02
Managing multiple clusters by manually running kubectl apply against each one individually doesn't scale, and genuinely risks CONFIGURATION DRIFT — two clusters that were supposed to be identical gradually diverging because a manual change was applied to one but forgotten on the other, exactly the kind of inconsistency Terraform's own state-based model (the broader DevOps roadmap this course draws from) exists to prevent for cloud infrastructure generally.
03
GITOPS is the practice of treating a GIT REPOSITORY as the single source of truth for a cluster's (or many clusters') desired state — instead of a human or a CI pipeline running kubectl apply directly against a cluster, a dedicated GITOPS CONTROLLER running INSIDE each cluster continuously watches a Git repository and reconciles the cluster to match whatever's actually committed there.
04
This is genuinely just Phase 0.1's reconciliation model, applied one level up — instead of a Deployment's controller reconciling pods to match a Deployment object, a GitOps controller (Argo CD and Flux are the two most prominent) reconciles an ENTIRE CLUSTER's state to match whatever manifests (or Helm charts, Phase 7) are committed in a designated Git repository, continuously, automatically, and DRIFT DETECTION becomes genuinely automatic: any manual, out-of-band change to the cluster is detected and can be automatically reverted back to match Git.
05
The practical shift this represents: a deployment is no longer 'someone runs a command against the cluster' — it's 'someone merges a pull request' (directly connecting to Git's own course, Phase 4.2's review workflow), and the actual application to the cluster happens automatically and identically regardless of which specific cluster is involved, since every cluster's GitOps controller is simply watching the same (or its own designated) Git repository independently.
06
This course deliberately stops here, at the conceptual overview — a full GitOps course (Argo CD/Flux in real depth, multi-cluster ApplicationSets, progressive delivery) is genuinely substantial enough to be its own dedicated Hectal course, exactly as CI/CD, AWS, and Observability are each substantial enough to be their own separate courses rather than additional phases bolted onto this one.

Code & diagrams

GitOpsReconciliationdiagram

The same reconciliation loop from Phase 0.1, now watching a Git repository instead of a single Kubernetes object.

Rendering diagram…

gitops-preview.shmarkdown

The shift from manual apply to Git as the real interface — a genuine preview, not the full picture a dedicated course would cover.

# The OLD way — someone (or a CI pipeline) applies directly
kubectl apply -f my-app-manifests/

# The GitOps way — a controller inside the cluster watches Git itself;
# "deploying" is just committing to the repo it's watching
git add my-app-manifests/deployment.yaml
git commit -m "Bump my-app to v1.6.0"
git push
# nothing else needed — the GitOps controller notices the new commit
# and reconciles the cluster to match it automatically, within its own polling interval

# Confirm the controller's own view of sync status (Argo CD example)
argocd app get my-app
# SYNC STATUS: Synced   <- cluster state matches the Git repo exactly

# Detect manual drift — change something directly, out of band
kubectl scale deployment my-app --replicas=10
argocd app get my-app
# SYNC STATUS: OutOfSync   <- the controller notices, and can auto-revert it

Explain it without notes

How is a GitOps controller's job conceptually the same as a Deployment's own controller reconciling ReplicaSets, from Phase 0.1 and Phase 1.1?

Why does GitOps make 'configuration drift' across multiple clusters a fundamentally smaller risk than manually running kubectl apply against each cluster separately?

Practice

If you have access to a cluster with Argo CD or Flux installed, find an existing Application/Kustomization object and check its sync status against the Git repository it's watching.

Think through, for a hypothetical team managing 3 separate clusters (dev/staging/production), one concrete way configuration drift could happen with manual kubectl apply, and how a GitOps approach would have prevented it.

Trade-offs

↔
GitOps provides genuinely strong consistency guarantees and a clear, auditable history of every change (since every change is a Git commit, with all the review and traceability benefits Git's own course covered), but it does mean every genuine change to a cluster must go through Git — a deliberate trade of some immediacy (no more quick, direct kubectl edit for an urgent fix) for consistency and auditability, which is exactly the right trade for most production systems, but worth recognizing as a real, deliberate constraint rather than a pure, cost-free upgrade.

Done when you can

I can explain GitOps as the same reconciliation model from Phase 0.1, applied to an entire cluster watching a Git repository.
I understand how GitOps reduces configuration drift risk across multiple clusters compared to manual kubectl apply.
I know this topic is a conceptual preview, and that Argo CD/Flux in real depth would be their own dedicated course.