Overview
Component Overview
The Cluster Autoscaler (CA) component offers auto-scaling (AS) capabilities for clusters based on simulated scheduling algorithms. It supports adding new nodes when resources are scarce and removing old nodes when resources are idle.
Note
This component must be used in conjunction with a node pool, and now it supports native nodes and regular nodes.
To use this capability, ensure that the node pool has AS enabled.
Kubernetes objects deployed in a cluster
|
cluster-autoscaler | PodDisruptionBudget | - | kube-system |
cluster-autoscaler | ServiceAccount | - | kube-system |
cluster-autoscaler | Secret | - | kube-system |
cluster-autoscaler | ClusterRole | - | - |
cluster-autoscaler | ClusterRoleBinding | - | - |
cluster-autoscaler | Role | - | kube-system |
cluster-autoscaler | RoleBinding | - | kube-system |
cluster-autoscaler | Service | - | kube-system |
cluster-autoscaler | Deployment | 0.5C1G (for new creations) | kube-system |
Application Scenario
When instances (pods) in the cluster cannot be scheduled due to insufficient resources, an auto scale-out action is triggered to add nodes of an appropriate type through simulated scheduling, reducing your labor costs.
When scale-in conditions are met, an auto scale-in action is triggered to remove nodes, saving you resource costs.
Limits
Kubernetes cluster version: 1.16 or later
Component Principles
Scale-out Principle
1. When the cluster lacks sufficient resources (the cluster's compute/storage/network resources cannot meet the Request/Affinity rules of pods), CA detects pods that are pending due to unschedulability.
2. CA makes scheduling decisions based on the node template of each node pool, selecting the appropriate node template.
3. If multiple templates are suitable, meaning there are multiple scalable node pools available, CA will call expanders to select the optimal template and scale out the corresponding node pool.
Scale-in Principle
1. CA detects that the allocation rate (namely, the Request value, which takes the maximum value of the CPU allocation rate and MEM allocation rate) is lower than the threshold specified for a node. When calculating the allocation rate, you can set the Daemonset type not to count in a pod's occupied resources.
2. CA checks whether the cluster's status meets the following requirements for triggering a scale-in action:
Node idle duration requirement (default: 10 minutes)
Cluster expansion buffer time requirement (default: 10 minutes)
3. CA checks whether a node meets the conditions for scale-in. You can configure the following do-not-remove conditions as needed (nodes that meet these conditions will not be removed by CA):
Nodes containing local storage.
Nodes containing pods that are not managed by DaemonSet in the kube-system namespace.
4. After evicting the pods on the node, CA releases/shuts down the node.
Completely idle nodes can be removed in batches. (The maximum number of nodes that can be removed in a batch can be set.)
Non-completely idle nodes are removed one by one.
Parameter description
|
Scale-out | Scale-out Algorithm | **Random (default)**: If there are multiple scalable node pools, any one of them will be selected for scaling out. Most-pods: If there are multiple scalable node pools, the node pool running the highest number of pods will be selected for scaling out. Least-waste: If there are multiple scalable node pools, the node pool with the least resource waste will be selected for scaling out. Priority: If there are multiple scalable node pools, the node pool with higher priority will be selected for scaling out according to your custom ConfigMap (see below for details). This feature is only supported by native node pools and is ineffective for regular node pools. |
Scale-in | Maximum Concurrent Scale-downs | The number of nodes that can be removed in a batch during a scale-in action. Note: Only completely idle nodes are removed in a batch. Nodes that contain any pods are removed one by one. |
| Scale-in Conditions | Threshold: Scale-in conditions are evaluated when the percentage of resources occupied by pods to allocable resources is less than x%. |
|
| Trigger latency: A node is removed after being continuously idle for x minutes. |
|
| Silent period: Scale-in conditions are evaluated x minutes after the cluster is scaled out. |
| Do Not Scale Down Nodes | Nodes containing pods with local storage (including hostPath and emptyDir). Nodes containing pods that are not managed by DaemonSet in the kube-system namespace. |
###Using a Scale-out Algorithm Based on the Priority in Custom ConfigMap
Note
This feature is only supported by native node pools and is ineffective for regular node pools.
Priority values range from 1 to 100 and must be positive integers.
A node pool ID maps one and only one priority.
If the node pool ID is not configured in ConfigMap, even if scale-out requirements are met, the scale-out action will not be performed because the priority is not configured.
Below is a sample:
apiVersion: v1
data:
priorities: |-
100:
- np-l5wmakan
50:
- np-9r9rh7kp
kind: ConfigMap
metadata:
name: cluster-autoscaler-priority-expander
namespace: kube-system
Related Links
Was this page helpful?