What are the differences between Cluster Autoscaler (CA) and node scaling based on monitoring metrics in elastic scaling?
Cluster Autoscaler (CA) ensures that all pods in the cluster can be scheduled regardless of the actual load, while node auto scaling based on monitoring metrics do not take pods into consideration during auto scaling. Therefore, nodes without pods might be added, or nodes with system-critical pods such as kube-dns might be deleted during auto scaling. Kubernetes discourages the latter auto scaling mechanism. In conclusion, these two modes conflict and should not be enabled at the same time.
How does CA work with auto scaling groups?
A CA-enabled cluster will, according to the configuration of the selected node, create a launch configuration and bind an auto scaling group to it. The cluster will then perform scale-in/out in this bound auto scaling group. CVM instances scaled out are automatically added to the cluster. Nodes that are automatically scaled in/out are billed on a pay-as-you-go basis. For more information about auto scaling group, see Auto Scaling (AS).
Can a node manually added in the TKE Console be scaled in by CA?
No. CA only scales in the nodes within the auto scaling group. Nodes that are added on the TKE Console are not added to the auto scaling group.
Can I add or remove CVM instances in the Auto Scaling Console?
What configurations of the selected node will be inherited during scaling?
When creating an auto scaling group, you need to select a node in the cluster as a reference to create a launch configuration. The node configuration for reference includes:
vCPU
Memory
System disk size
Data disk size
Disk type
Bandwidth
Bill-by-bandwidth mode
Whether to assign public IP
Security Group
VPCs
Subnets
How do I use multiple auto scaling groups?
Based on the level and type of the service, you can create multiple auto scaling groups, set different labels for them, and specify the label for the nodes scaled out in the auto scaling groups to classify the service.
What is the maximum quota for scaling?
Currently, Tencent Cloud users have a quota of 30 pay-as-you-go CVM instances per availability zone. If you wish to have more than 30 pay-as-you-go CVM instances in an auto scaling group, please contact support to apply. For specific quotas, refer to the Instance Count and Quota for your current availability zone. Additionally, there is a maximum limit for elastic scaling, which is set at 200. If you wish to scale beyond this limit, please contact support to apply.
Is scale-in safe for the cluster?
Since pods will be rescheduled when a node is scaled in, scale-in can be performed only if the service can tolerate rescheduling and short-term interruption. We recommend using PDB. PDB can specify the minimum number/percentage of replicas for a pod set that remains available at all times. With PodDisruptionBudget, application deployers can make sure that the cluster operations that actively remove pods will not terminate too many pods at a time, which helps prevent data loss, service interruption, or unacceptable service degradation.
What types of pods in a node will not be scaled in?
If the Pod for which you set strict PDB does not satisfy the PDB, it will not be scaled down.
There are Pods under the Kube-system.
On the node there are Pods that are not created by controllers such as Deployment, ReplicaSet, Job, or StatefulSet.
There are Pods with local storage.
Pods that cannot be scheduled to another node.
How long does it take to trigger scale-in after the condition is met?
10 minutes.
How long does it take to trigger scale-in when the node is marked as Not Ready?
20 minutes.
How often is a node scanned for scaling?
Every 10 seconds.
How long does it take to scale out a CVM instance?
Why is a node with an unschedulable pod not scaled out?
Please check the following:
Whether the requested resource of the pod is too large.
Whether a node selector is set.
Whether the maximum number of nodes in the auto scaling group has been reached.
Please ensure that your account balance is sufficient (insufficient balance will prevent elastic scaling from expanding) and check for other reasons such as insufficient quota. For more information, see Troubleshooting Elastic Scaling Issues.
How can I prevent CA from scaling in a specific node?
You can set the following information in the node's annotations:kubectl annotate node <nodename> cluster-autoscaler.kubernetes.io/scale-down-disabled=true
How can I view the TKE node scaling events?
You can view the scaling activities of the auto scaling group in the Elastic Scaling Console and check the k8s events. Corresponding events will be available on the following three resources:
kube-system/cluster-autoscaler-status config map
Resources | Event |
ScaledUpGroup | CA initiates scaling out. |
ScaleDownEmpty | CA removed a node that had no running Pods. |
ScaleDown | CA scale-in. |
node
Resources | Event |
ScaleDown | CA scale-in. |
ScaleDownFailed | Unable to scale in by CA. |
pod
Resources | Event |
TriggeredScaleUp | CA scales out due to this Pod. |
NotTriggerScaleUp | CA cannot find a suitable auto scaling group to scale out, making the Pod unschedulable. |
ScaleDown | CA attempts to drain the Pod in order to scale in the node. |
Can the kube-proxy mode of a container cluster be changed?
Kube-proxy proxy mode supports iptables and ipvs, which can be selected during cluster creation. However, once the cluster is created, the mode cannot be changed. For more information, see Enabling IPVS for a Cluster.