Skip to content

Latest commit

 

History

History
168 lines (130 loc) · 8.93 KB

README.md

File metadata and controls

168 lines (130 loc) · 8.93 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.

Technical Leads

The Technical Leads of the SIG establish new subprojects, decommission existing subprojects, and resolve cross-subproject technical issues and decisions.

Contact

Subprojects

The following subprojects are owned by sig-scalability:

kubernetes-scalability-and-performance-tests-and-validation

Described below

kubernetes-scalability-bottlenecks-detection

Described below

kubernetes-scalability-definition

Described below

kubernetes-scalability-governance

Described below

kubernetes-scalability-test-frameworks

Described below

Scalability Regression - Contact Points

Reach out to these folks if you have any inquiries about scalability regressions, e.g. regression status, whether it should block the release or not, etc.

Upcoming 2019 Meeting Dates

  • 07/04
  • 07/18
  • 08/01
  • 08/15
  • 08/29
  • 09/12
  • 09/26
  • 10/10
  • 10/24
  • 11/07
  • 11/21
  • 12/05
  • 12/19

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.