community/sig-autoscaling

Autoscaling Special Interest Group

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

The charter defines the scope and governance of the Autoscaling Special Interest Group.

Meetings

• Regular SIG Meeting: Mondays at 16:00 Poland (weekly). Convert to your timezone.
  • Meeting notes and Agenda.

Leadership

Chairs

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

• Guy Templeton (@gjtempleton), Skyscanner
• Marcin Wielgus (@mwielgus), Google

Contact

• Slack: #sig-autoscaling
• Mailing list
• Open Community Issues/PRs
• GitHub Teams:
  • @kubernetes/sig-autoscaling-api-reviews - API Changes and Reviews
  • @kubernetes/sig-autoscaling-bugs - Bug Triage and Troubleshooting
  • @kubernetes/sig-autoscaling-feature-requests - Feature Requests
  • @kubernetes/sig-autoscaling-misc - General Discussion
  • @kubernetes/sig-autoscaling-pr-reviews - PR Reviews
  • @kubernetes/sig-autoscaling-proposals - Design Proposals
  • @kubernetes/sig-autoscaling-test-failures - Test Failures and Triage
• Steering Committee Liaison: Derek Carr (@derekwaynecarr)

Subprojects

The following subprojects are owned by sig-autoscaling:

addon-resizer

• Owners:
  • kubernetes/autoscaler/addon-resizer

cluster-autoscaler

• Owners:
  • kubernetes/autoscaler

horizontal-pod-autoscaler

• Owners:
  • kubernetes/api/autoscaling
  • kubernetes/kubernetes/pkg/controller/podautoscaler

scale-client

• Owners:
  • kubernetes/client-go/scale

vertical-pod-autoscaler

• Owners:
  • kubernetes/autoscaler

Concerns

• autoscaling of clusters,
• horizontal and vertical autoscaling of pods,
• setting initial resources for pods,
• topics related to monitoring pods and gathering their metrics (e.g.: Heapster)

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.