GitOps at Scale with Flux: The Cluster Is the Pull Request

In GitOps, Git is the single source of truth and a controller continuously reconciles the cluster toward it. No more kubectl apply from laptops, no more drift nobody can explain, the desired state is a commit, and the review is a pull request.

The cluster reconciles to Git

Point Flux at a repo and tell it what to apply. From then on, a merge is a deploy and a revert is a rollback:

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata: { name: platform, namespace: flux-system }
spec:
 interval: 1m
 url: https://github.com/acme/platform
 ref: { branch: main }
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata: { name: apps, namespace: flux-system }
spec:
 interval: 5m
 path: ./clusters/prod
 prune: true # deletes what you removed from Git
 sourceRef: { kind: GitRepository, name: platform }
 wait: true # block until healthy

The prune: true flag is the quiet superpower: delete a manifest from Git and Flux removes it from the cluster. State converges, both ways.

Safer than push-based CI

• No cluster credentials in CI, the controller pulls, nothing pushes in

• Drift is detected and corrected automatically

• Every change is reviewed, attributable, and revertible

• Multi-cluster fleets stay consistent from one repo structure

Operating it

flux get kustomizations --all-namespaces # what is reconciling
flux reconcile kustomization apps --with-source # force a sync now
flux suspend kustomization apps # freeze during an incident

If it is not in Git, it is not real. If it is in Git, the cluster will make it real.

GitOps trades imperative heroics for declarative calm. The audit log is your commit history, the rollback is a revert, and the cluster spends its life catching up to what you already reviewed.