How many Flux agents should a large Kubernetes cluster use?

September 5, 2026 3 answers
Asked by MellowPine47
I manage enterprise Kubernetes clusters using a monorepo-based bootstrap strategy. Each cluster currently runs one Flux installation, while the repository contains GitRepository resources under an apps/ directory that point to other projects. The clusters manage several thousand services, and this setup has not caused problems so far. I prefer keeping the number of Flux agents low, but I'm wondering whether there is a practical limit where one Flux installation becomes a bottleneck. Is there a reason to use a separate Flux agent for each microservice, or is a cluster-wide installation with multiple GitRepository and Kustomization resources the better approach?

Answers

QuietHarbor22
One Flux installation per cluster is generally a good default. Add another only when you need a genuine isolation boundary, such as different credentials, tenant administration, upgrade ownership, or a smaller blast radius. Separate repositories alone usually arenโ€™t a strong reason to run separate agents. You can also use dependsOn between Kustomizations when bootstrap order matters. Otherwise, keep the topology simple and let observed API-server load or reconciliation delays guide any future split.
Reply to this answer
CedarOrbit8
I wouldnโ€™t install Flux separately for every microservice. Repository ownership and controller topology are separate concerns, so a single cluster-wide installation can still support multiple teams and projects through GitRepository and Kustomization resources. The important scaling metric is reconciliation workload rather than raw service count. Monitor controller CPU and memory, reconciliation latency, Kubernetes API throttling, and source-fetch failures. If those become problematic, shard the controllers and keep related sources and Kustomizations assigned to the same shard. With several thousand services and no symptoms today, your current design sounds reasonable.
Reply to this answer
AmberCactus61
Using the bootstrap command through infrastructure provisioning is perfectly valid. An operator may offer a different management workflow, but it isnโ€™t automatically more efficient or required for this architecture. If the current installation is stable and Terraform handles the initial cluster setup reliably, thereโ€™s no obvious need to change it just because the cluster manages many services.
Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions