Skip to content

Latest commit

 

History

History
158 lines (122 loc) · 8.22 KB

README.md

File metadata and controls

158 lines (122 loc) · 8.22 KB

Scalability Special Interest Group

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.

Meetings

Leadership

Chairs

The Chairs of the SIG run operations and processes governing the SIG.

Contact

Subprojects

The following subprojects are owned by sig-scalability:

GitHub Teams

The below teams can be mentioned on issues and PRs in order to get attention from the right people. Note that the links to display team membership will only work if you are a member of the org.

Team Name Details Description
@kubernetes/sig-scalability-api-reviews link API Changes and Reviews
@kubernetes/sig-scalability-bugs link Bug Triage and Troubleshooting
@kubernetes/sig-scalability-feature-requests link Feature Requests
@kubernetes/sig-scalability-misc link General Discussion
@kubernetes/sig-scalability-pr-reviews link PR Reviews
@kubernetes/sig-scalability-proprosals link Design Proposals
@kubernetes/sig-scalability-test-failures link Test Failures and Triage

Upcoming 2019 Meeting Dates

  • 12/20/2018
  • 1/3
  • 1/17
  • 1/31
  • 2/14
  • 2/28
  • 3/14
  • 3/28
  • 4/11
  • 4/25
  • 5/9
  • 5/23
  • 6/6
  • 5/20

Details about SIG-Scalability sub-projects

Kubernetes scalability definition

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.

Kubernetes scalability governance

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.

Kubernetes scalability test frameworks

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.

Kubernetes scalability and performance tests and validation

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:

Kubernetes scalability bottlenecks detection

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.