SIG Autoscaling

Covers development and maintenance of components for automated workload and node scaling in Kubernetes. This includes automated vertical and horizontal pod autoscaling (workload autoscaling), initial workload resource estimation, cluster-proportional system component autoscaling, and autoscaling of Kubernetes clusters themselves (node autoscaling).

Meetings

Joining the mailing list for the group will typically add invites for the following meetings to your calendar.

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.

Emeritus Leads

Contact

Working Groups

The following working groups are sponsored by sig-autoscaling:

Subprojects

The following subprojects are owned by sig-autoscaling:

addon-resizer

cluster-autoscaler

horizontal-pod-autoscaler

karpenter

vertical-pod-autoscaler

How To Contribute a Sub-Project to the SIG

SIG Autoscaling welcomes project candidates (either new or existing) for official sponsorship, with the following requirements:

  • Any project proposed for donation must address an unsolved problem that falls under SIG charter .
  • Project must demonstrate that the problem is worth solving:
    • Addresses real, demonstrated user concerns
    • Unblocks other projects or efforts in the Kubernetes ecosystem
    • Reduces the overall problem space, i.e., doesn’t introduce more problems
  • Solutions from a project proposed for donation should not intersect with the published roadmap of one or more existing SIG-sponsored projects. (Default is to prefer addressing well-known, scoped problems within existing community projects.)
    • SIG-sponsored project owners may advocate for exploring problems that intersect with existing projects’ problem spaces independently; that blessing should be documented publicly.
  • Any project proposed for donation should include stakeholders (code contributor and/or project maintainer) from more than one company.
    • An exception can be made if demonstrated outreach to the larger community can be proven: sometimes general solutions can intersect with a single entity stakeholder/investor.
  • Any project proposed for donation should have at least three active Kubernetes org members who will maintain the project, expressed in an OWNERS file.

In addition to the above, any project proposed for donation will adhere to the general requirements for Kubernetes SIG repositories , and is subject to final acceptance review and approval by SIG Autoscaling Leads.

If your project meets the above criteria, please attend a weekly SIG meeting to announce your intent, and to take community feedback. In addition, after the public announcement of intent in the SIG meeting, please broadcast a public message to the SIG Autoscaling user group , and include the following:

  • Brief overview of your project, its intended scope, and the reasons why SIG Autoscaling sponsorship will deliver maximum value to the Kubernetes customer and developer communities.
  • Any existing project references, existing GitHub repositories, design docs
  • Evidence of user value proposition (e.g., open issues in Kubernetes development ecosystem, slack threads)
  • State concrete, time-bound goals for your project with SIG Autoscaling (e.g., a user-informed beta API within 18 months) so that the SIG can deterministically wind down the project effort if goals are not met (the SIG can’t host infinite sub-projects forever).

Demo and Presentation Guidelines

If you want to demo at SIG Autoscaling, we have some guidelines:

  • Demos should talk about open-source projects relevant to Kubernetes autoscaling, such as:

    • Prototypes for features to be added to Kubernetes
    • Projects that fill gaps in our infrastructure that we might want to address
    • Alternative approaches to what we do now that we may want to research

  • Demos and presentations should be geared towards a techincal audience.

  • Demos and presentations should not talk about company history or background, except to provide context for a usecase or issue:

    • “We’re a retail company, and people don’t shop as much during at 3am, so we generally see patterns of traffic around times” is acceptable.

    • Giving a company elevator pitch is not acceptable.

  • Non-demo presentations should focus on usecases and issues. A good rule of thumb is that content should be relevant in some form to a design doc or KEP’s motivation or background sections. If it’s not, it probably doesn’t belong in the presentation.

  • Demos and presentations should not pitch products. If you want to talk about a product that’s recently been open-sourced, focus on it from the perspective of why it’s useful to the community.