SIG Autoscaling Charter and sigs.yaml updates #2425
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,85 @@ | ||
| # SIG Autoscaling Charter | ||
|
|
||
| This charter adheres to the conventions described in the [Kubernetes Charter README] and uses | ||
| the Roles and Organization Management outlined in [sig-governance]. | ||
|
|
||
| ## Scope | ||
|
|
||
| Covers development and maintenance of Kubernetes 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. | ||
|
|
||
| ### In scope | ||
|
|
||
| - Autoscaling-related API objects, such as the HorizontalPodAutoscaler and | ||
| VerticalPodAutoscaler | ||
|
|
||
| - Autoscaling-related tools, such as the cluster autoscaler, | ||
| single-component scaling tools (e.g. pod-nanny), and | ||
| cluster-proportional scaling tools | ||
|
|
||
| - Ensuring API interfaces (the scale subresource) are available and usable | ||
| to enable other SIGs to write autoscalable objects, and enable people to | ||
| interact with those interfaces. | ||
|
There was a problem hiding this comment. I'd argue this goes requires a lot of apimachinery know-how, which is not too closely related to anything else we do in sig. I suspect you're the only one who actually knows how the polymorphic scale client actually works. There was a problem hiding this comment. Sure, but we're responsible for maintaining the HPA, and the HPA can't work w/o the scale subresource, and the scale subresource's object is part of the autoscaling API group. @kubernetes/sig-api-machinery-misc any opinions? There was a problem hiding this comment. In general, api-machinery owns mechanisms, specific sigs own specific APIs. In this case, I'd expect api-machinery to own the apiserver code that enables subresources, and autoscaling to own the in-tree scale subresource implementations, the autoscaling/v1 Scale API types, and custom code in the scale client. There was a problem hiding this comment. ack, that's more-or-less what I expected |
||
|
|
||
| [Link to SIG section in sigs.yaml][sigs.yaml] | ||
|
|
||
| #### Code, Binaries and Services | ||
|
|
||
| - Components and utilities that take automated action to scale a component | ||
|
There was a problem hiding this comment. These are all kind of vague, pointers to actual repos/folders? There was a problem hiding this comment. I was under the impression that concrete folders is what sigs.yaml was supposed to be for, and that this was more of "conceptually, what do you cover". That being said, I can certainly provide some examples here, or actually links if my impression was incorrection. There was a problem hiding this comment. fixed to mention the actual subproject names |
||
| on the cluster (e.g. the horizontal-pod-autoscaler or addon-resizer | ||
| subproject) | ||
|
|
||
| - Components and utilities that take automated action to scale the cluster | ||
| itself (e.g. the cluster-autoscaler subproject) | ||
|
|
||
| - Special parts of client-go for interacting with with the scaling | ||
|
There was a problem hiding this comment. Definitely need a pointer into the project here. There was a problem hiding this comment. done -- mentioned the specific subproject. Actual folder definitions are in sigs.yaml |
||
| interfaces used by the HPA (e.g. the scale-client subproject) | ||
|
|
||
| #### Cross-cutting and Externally Facing Processes | ||
|
|
||
| - Reviewing implementations of the scale subresource to ensure that | ||
| autoscaling behaves properly | ||
|
|
||
| - Coordinating with SIG Instrumentation to ensure that metrics APIs are | ||
| suitable for autoscaling on. | ||
|
There was a problem hiding this comment. Can we add coordinating with sig-scheduling to ensure new scheduling features are compatible with cluster autoscaling? |
||
|
|
||
| - Coordinating with SIG Scheduling to make sure scheduling decisions can | ||
| interact well with the cluster autoscaler | ||
|
|
||
DirectXMan12 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - Coordinating with SIG Cluster Lifecycle on integration between the | ||
| cluster autoscaler and cluster API | ||
|
|
||
| - Coordinating with SIG Node around Kubelet requirements for vertical | ||
| scaling of pods | ||
|
|
||
| ### Out of scope | ||
|
|
||
| - Testing general cluster performance at scale (this falls under the | ||
| purview of [SIG Scalability]). | ||
|
|
||
| - Owning metrics APIs (this falls under the purview of [SIG | ||
DirectXMan12 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| Instrumentation]). SIG Autoscaling should collaborate with [SIG | ||
| Instrumentation] to ensure that metrics APIs are suitable for using in | ||
| autoscaling. | ||
|
|
||
| ## Roles and Organization Management | ||
|
|
||
| This sig follows adheres to the Roles and Organization Management outlined in [sig-governance] | ||
| and opts-in to updates and modifications to [sig-governance]. | ||
|
|
||
| ### Deviations from [sig-governance] | ||
|
|
||
| - SIG Autoscaling does not have chairs as a separate entity from tech | ||
| leads. The tech leads have the responsibility of chairs. | ||
|
|
||
| ### Subproject Creation | ||
|
|
||
| SIG Technical Leads | ||
|
|
||
| [sig-governance]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md | ||
| [sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml#L305 | ||
| [Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md | ||
| [SIG Scalability]: https://github.com/kubernetes/community/blob/master/sig-scalability | ||
| [SIG Instrumentation]: https://github.com/kubernetes/community/blob/master/sig-instrumentation | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently cluster proportional autoscaling is not owned by sig-autoscaling:
Ideally sig-autoscaling should take ownership of this use-case, but we're not there yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, do we not own the addon-resizer? I thought it was under our purview from the pre-sig-instrumentation Heapster days, and I didn't think it got transferred over, since it's an autoscaler.
We probably should own those, at any rate. @kubernetes/sig-instrumentation-misc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was not aware of this, and it's also not in our sig components. I was under the impression that sig-autoscaling own it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean no-one is really doing much work on addon-resizer, but I believe @kawych and @x13n are the ones maintaining it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every kubernetes piece of code needs to be owned by a SIG. I think it makes sense for us to own it, especially since it doesn't fall under the responsibilities of SIG instrumentation normally. @kawych and @x13n can continue to be the ones to work on it, and we can list them as the owners of the subproject, but it'll fall under the purview of sig autoscaling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DirectXMan12’s suggestion sounds good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kubernetes/sig-network-misc the cluster-proportional-autoscaler doesn't seem to be listed under
sigs.yaml(unless my searching is failing me). I think it makes some amount of sense for it to be a subproject of sig-autoscaling (no change in ownership necessary, but it should fall under a sig umbrella), so I'd appreciate your opinions.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DirectXMan12 what you suggested sounds great. Also wanted to point out yet another component that might fall under this same umbrella: cluster-proportional-vertical-autoscaler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool, thanks for the heads up. I'll update sigs.yaml with all of those
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this SIG owns an incubator project, unless it was created by SIG members who want it to be within the scope of the SIG...