SIG Scalability is responsible for defining and driving scalability goals for Kubernetes. We also coordinate and contribute to general system-wide scalability and performance improvements (not falling into the charter of other individual SIGs) by driving large architectural changes and finding bottlenecks, as well as provide guidance and consultations about any scalability and performance related aspects of Kubernetes.
We are actively working on finding and removing various scalability bottlenecks which should lead us towards pushing system's scalability higher. This may include going beyond 5k nodes in the future - although that's not our priority as of now, this is very deeply in our area of interest and we are happy to guide and collaborate on any efforts towards that goal as long as they are not sacrificing on overall Kubernetes architecture (by making it non-maintainable, non-understandable, etc.).
The charter defines the scope and governance of the Scalability Special Interest Group.
- Regular SIG Meeting: Thursdays at 18:30 Warsaw (bi-weekly (upcoming meeting dates)). Convert to your timezone.
The Chairs of the SIG run operations and processes governing the SIG.
The Technical Leads of the SIG establish new subprojects, decommission existing subprojects, and resolve cross-subproject technical issues and decisions.
- Wojciech Tyczynski (@wojtek-t), Google
- Slack: #sig-scalability
- Mailing list
- Open Community Issues/PRs
- GitHub Teams:
- @kubernetes/sig-scalability-api-reviews - API Changes and Reviews
- @kubernetes/sig-scalability-bugs - Bug Triage and Troubleshooting
- @kubernetes/sig-scalability-feature-requests - Feature Requests
- @kubernetes/sig-scalability-misc - General Discussion
- @kubernetes/sig-scalability-pr-reviews - PR Reviews
- @kubernetes/sig-scalability-proprosals - Design Proposals
- @kubernetes/sig-scalability-test-failures - Test Failures and Triage
The following subprojects are owned by sig-scalability:
- Owners:
- Owners:
- Owners:
- Owners:
- https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/images/kubemark/OWNERS
- https://raw.githubusercontent.com/kubernetes/kubernetes/master/cmd/kubemark/OWNERS
- https://raw.githubusercontent.com/kubernetes/kubernetes/master/pkg/kubemark/OWNERS
- https://raw.githubusercontent.com/kubernetes/kubernetes/master/test/kubemark/OWNERS
- https://raw.githubusercontent.com/kubernetes/perf-tests/master/OWNERS
- https://raw.githubusercontent.com/kubernetes/perf-tests/master/clusterloader2/OWNERS
SIG Scalability has established best-effort oncall rotation operating in CEST/CET business hours (~9:00-18:00). If you have any inquiries about scalability regressions, e.g. regression status, whether it should block the release or not, etc. please reach out to the current oncaller. They can be found on https://go.k8s.io/oncall .
Also do not hesitate to contact those SIG members for status update:
- Jacek Kaniuk (@jkaniuk), Google
- Jakub Przychodzeń (@jprzychodzen), Google
- Janek Lukasiewicz (@oxddr), Google
- Maciej Borsz (@mborsz), Google
- Matt Matejczyk (@mm4tt), Google
- Wojciech Tyczynski (@wojtek-t), Google
- 01/30
- 02/13
- 02/27
- 03/12
- 03/26
- 04/09
- 04/23
- 05/07
- 05/21
- 06/04
- 06/18
The following document lists regressions and bugs that SIG Scalability has been working on.
Scalability Regressions and Bugs
Defining what does it mean that "Kubernetes scales". This includes defining (or approving) individual performance and scalability related SLIs/SLOs, ensuring they are all oriented on user experience and consistent with each other.
Measuring and publishing limits within which Kubernetes is supposed to scale as defined above and providing recommendations about setting clusters in scalable and performant ways.
Establishing and documenting best practises on how do design and implement Kubernetes features in scalable and performance way. Educating contributors and ensuring best practises are widely used.
Designing and creating frameworks to make scalability and performance testing of Kubernetes easy and available for all contributors. Different frameworks may help in different aspects of scalability testing, enabling making conscious tradeoffs, e.g. cost vs accuracy or real life vs more generalized benchmarking scenarios.
Ensuring that all tests necessary to validate Kubernetes scalability and performance exists (ideally by providing easy-to-use frameworks and working with SIGs to provide them), having engironment and resources to run them.
Ensuring that tests are being executed according to calendar and ensuring that each official Kubernetes release satisfies all scalability and performance requirements as stated in "Kubernetes scalability" definition. This also includes designing processes to reduce maintenance work and number of scalability and performance regressions:
We are in progress to migrating tests to new framework:
Detecting scalability bottlenecks and limitations, documenting them and driving architectural changes to eliminate those (if such are required) in collaboration with other SIGs or directly delegating improvements to individual SIGs, of bottlenecks aren't cross-cutting the whole system.