How many Flux agents should a large Kubernetes cluster use?

0
0
Asked By MellowPine47 On

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?

3 Answers

Answered By AmberCactus61 On

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.

Answered By CedarOrbit8 On

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.

Answered By QuietHarbor22 On

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.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.