|
|
||
|---|---|---|
| .. | ||
| README.md | ||
README.md
KEP-5546: Scaling based on container count
Summary
Currently Addon Resizer supports scaling based on the number of nodes. Some workloads use resources proportionally to the number of containers in the cluster. Since number of containers per node is very different in different clusters it's more resource-efficient to scale such workloads based directly on the container count.
Goals
- Allow scaling workloads based on count of containers in a cluster.
- Allow this for Addon Resizer 1.8 (used by metrics server).
Non-Goals
- Using both node and container count to scale workloads.
- Bringing this change to the
masterbranch of Addon Resizer.
Proposal
Add flag --scaling-mode to Addon Resizer on the addon-resizer-release-1.8 branch. Flag will
have two valid values:
node-proportional- default, current behavior.container-proportional- addon resizer will set resources, using the same algorithm it's using now but using number of containers where it's currently using number of nodes.
Notes
Addon Resizer 1.8 assumes in multiple places that it's scaling based on the number of nodes:
- Flag descriptions that directly reference node counts (
--extra-cpu,--extra-memory,--extra-storage, and--minClusterSize) will need to be updated to instead refer to cluster size. - README will need to be updated to reference cluster size instead of node count and explain that cluster size refers
to either node count or container count, depending on the value of the
--scaling-modeflag. - Many variable names in code which now refer to node count will refer to cluster size and should be renamed accordingly.
In addition to implementing the feature we should also clean up the code and documentation.
Risks and Mitigations
One potential risk is that Addon resizer can obtain cluster size (node count or container count):
- from metrics or
- by querying Cluster Api Server to list all objects of the appropriate type
depending on the configuration. There can be many times more containers in a cluster that there are nodes. So listing all containers could result in higher load on the Cluster API server. Since Addon Resizer is requesting very few fields I don't expect this effect to be noticeable.
Also I expect metrics-server to test for this before using the feature and any other users of Addon Resizer are likely better off using metrics (which don't have this problem).
Design Details
- Implement function
kubernetesClient.CountContainers(). It will be analogous to the existingkubernetesClient.CountNodes()function.- If using metrics to determine number of containers in the cluster:
- Fetch pod metrics (similar to fetching node metrics but use
/podsURI instead of/nodes). - For each pod obtain number of containers (length of the
containersfield). - Sum container counts for all pods.
- Fetch pod metrics (similar to fetching node metrics but use
- If using API server:
- Fetch list pods (similar to listing nodes)
- Fetch only
Spec.InitContainers,Spec.Containers, andSpec.EphemeralContainersfields. - Exclude pods in terminal states (selector excluding pods in terminal states in VPA)
- Fetch only
- Sum container count over pods.
- Fetch list pods (similar to listing nodes)
- If using metrics to determine number of containers in the cluster:
- Add the
--scaling-modeflag, with two valid values:node-proportional- default, current behavior, scaling based on clusters node count andcontainer-proportional- new behavior, scaling based on clusters container count
- Pass value indicating if we should use node count or container count to the
updateResources()function. - In
updateResources()use node count or container count, depending on the value.
Check that listing containers directly works
Coinsider listing pods, getting containers only for working pods
Test Plan
In addition to unit tests we will run manual e2e test:
- Create config based on
example.yamlbut scaling the deployment based on the number of containers in the cluster. - Create config starting deployment with 100
pausecontainers.
Test the feature by:
- Starting the deployment scaled by Addon Resizer, based on node count.
- Observe size of the deployment and that it's stable.
- Start deployment with 100
pausecontainers. - Observe the scaled deployment change resources appropriately.
Test the node-based scaling:
- Apply
example.yaml. - Observe amount and stability assigned resources.
- Resize cluster.
- Observe change in assigned resources.
Both tests should be performed with metrics- and API- based scaling.