Member-only story
Featured
How I Would Design GitOps for 100+ Kubernetes Clusters
At 5 clusters, GitOps is a tool choice. At 100, it’s an architecture problem.
GitOps at five clusters is a solved problem. You pick a tool, Argo CD or Flux, set up your repository structure, configure ApplicationSets, and manage environments as overlays. The patterns are well-documented and the failure modes are recoverable.
At 100+ clusters, several assumptions break. A single Argo CD instance managing 100 clusters creates a single point of failure for your entire deployment infrastructure. A monorepo that receives 50 commits per day across 20 teams generates noise that makes the repository hard to reason about. A bad commit that triggers an automated sync across all 100 clusters simultaneously turns a deployment mistake into a fleet-wide incident.
The architecture decisions at this scale are different, and the cost of getting them wrong is proportionally higher.
The first decision: centralized vs federated Argo CD
This is the most consequential architectural choice. Get it wrong and you’ll spend months recovering.
Centralized Argo CD runs a single control plane that manages all clusters. Simpler to operate, single pane of glass…
