GitOps fails when the repository stops meaning anything
Flux is excellent at reconciling declared state. It is much less helpful when the repository mixes experiments, one-off overrides, and unclear environment ownership.
FluxCD is often described as “Kubernetes applies from Git,” but that phrasing undersells the real point. Flux is valuable because it creates a continuous, observable reconciliation loop from declared intent to cluster state.
That only works well when the intent is structured clearly.
Start with predictable reconciliation units
The GitRepository and Kustomization resources should reflect actual
ownership and rollout boundaries. If everything reconciles from one giant root
without dependencies or health expectations, teams lose control even though the
tooling is technically working.
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
name: platform-config
namespace: flux-system
spec:
interval: 1m
ref:
branch: main
url: https://github.com/example/platform-config
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: ingress
namespace: flux-system
spec:
interval: 5m
path: ./clusters/prod/ingress
prune: true
sourceRef:
kind: GitRepository
name: platform-config
wait: true
This is already more useful than a single reconciliation unit for the entire cluster.
Use dependencies where order actually matters
Flux supports dependsOn for a reason. Controllers, CRDs, shared networking,
and secrets operators often need to exist and become healthy before dependent
workloads are reconciled. Making that ordering explicit improves rollout
behavior and reduces confusing failure modes.
Treat prune as operational hygiene
If resources are removed from source, the cluster should usually stop carrying them. Teams that avoid prune often end up with drift they no longer understand. That does not mean prune should be careless, but it should usually be part of the design instead of something feared by default.
Closing view
FluxCD adds the most value when it reinforces release discipline. Clear sources, clear reconciliation units, explicit dependencies, and health-aware rollouts are what make GitOps real. Without those, the cluster may still converge, but the team will have less confidence in what convergence actually means.