Breaking GitOps Bottlenecks: The Power of Sharding
summary
Single-controller GitOps hits resource limits as teams and changes scale, and simply bumping CPU/memory is only a stopgap; sharding controllers instead splits work and in one example a single overloaded controller becomes three and stops crashing. Argo city supports cluster-level sharding with hash/mod, round‑robin, constant hashing and manual assignment (all currently alpha and prone to uneven redistribution), while Flux city supports resource-level sharding via smaller, microservice controllers but lacks automatic algorithms, so manual labels add operational overhead. Monitor controller resource use and pick cluster vs resource sharding based on workload shape.
AI-written summary · about
chapters (10)
- 0:00GitOps introduction
- 1:43GitOps bottlenecks
- 3:59Controller overload signs
- 5:03Sharding controllers
- 6:49Argo CD vs Flux CD
- 10:05Argo CD sharding limits
- 11:56Flux CD resource sharding
- 13:43Choosing sharding tool
- 14:45Monitoring controllers
- 15:07Q&A
related talks
31mBeyond the Limits: Scaling Kubernetes Controllers Horizontally
32mLessons learnt from implementing GitOps and Continuous Delivery at scale
28mManaging GitOps as a Platform Service
07mIntroduction to GitOps
29mWhen GitOps Becomes the Bottleneck: Scaling Argo CD for High-Churn Platforms
43mConfiguration as Data, GitOps and Multi Cluster The Key to Successful Servic
37mPanel: Building a GitOps...
32mGitOps at Scale: Why Your Hub-and-Spoke Architecture is a Security Risk