|
Deployment |
concurrent-deployment-syncs |
Number of deployment objects that are allowed to sync concurrently |
Default: 5 |
Console/API |
|
Endpoint |
concurrent-endpoint-syncs |
Number of service endpoint syncing operations that will be done concurrently |
Default: 5 |
Console/API |
|
Garbage Collection |
concurrent-gc-syncs |
Number of garbage collector workers that can be synchronized concurrently |
Default: 20 |
Console/API |
|
Job |
concurrent-job-syncs |
Number of job objects that can be synchronized concurrently |
Default: 5 |
Console/API |
|
CronJob |
concurrent-cron-job-syncs |
Number of scheduled jobs that can be synchronized concurrently |
Default: 5 |
Console/API |
|
Namespace |
concurrent-namespace-syncs |
Number of namespace objects that can be synchronized concurrently |
Default: 10 |
Console/API |
|
ReplicaSet |
concurrent-replicaset-syncs |
Number of replica sets that can be synchronized concurrently |
Default: 5 |
Console/API |
|
Resource Quota |
concurrent-resource-quota-syncs |
Number of resource quotas that can be synchronized concurrently |
Default: 5 |
Console/API |
|
Service |
concurrent-service-syncs |
Number of services that can be synchronized concurrently |
Default: 10 |
Console/API |
|
Service Account Tokens |
concurrent-serviceaccount-token-syncs |
Number of service account token objects that can be synchronized concurrently |
Default: 5 |
Console/API |
|
TTLAfterFinished |
concurrent-ttl-after-finished-syncs |
Number of ttl-after-finished workers that can be synchronized concurrently |
Default: 5 |
Console/API |
|
RC |
concurrent_rc_syncs (used in clusters v1.19 or earlier)
concurrent-rc-syncs (used in clusters v1.21 through v1.25.3-r0) |
Number of replication controllers that can be synchronized concurrently
This parameter is deprecated in clusters v1.25.3-r0 and later versions. |
Default: 5 |
Console/API |
|
HPA synchronization period |
horizontal-pod-autoscaler-sync-period |
The period of horizontal pod autoscaler for syncing the number of pods. A smaller value will result in a faster auto scaling response and higher CPU load.
Configuration suggestion: Retain the default setting.
Potential risks: If the period is too long, HPA will respond slowly. If it exceeds the upper limit (153,722,867 minutes), system components may malfunction. If the period is too short, the cluster management plane will be overloaded. |
Default: 15s |
Console/API |
|
Horizontal Pod Scaling Tolerance |
horizontal-pod-autoscaler-tolerance |
The configuration determines how quickly HPA will act to auto scaling policies. If the parameter is set to 0, auto scaling will be triggered immediately when the related metrics are met.
Configuration suggestion: Configure this parameter based on service resource usage. If the service resource usage increases sharply over time, configure a tolerance to prevent unexpected auto scaling in short-term high-resource usage scenarios. |
Default: 0.1 |
Console/API |
|
HPA CPU initialization period |
horizontal-pod-autoscaler-cpu-initialization-period |
During this period, HPA can only utilize the metrics of a pod if the pod is ready and its latest metric collection is finished. You can use this parameter to filter out unstable CPU usage data during the early stage of pod startup. This helps prevent incorrect scaling decisions based on momentary peak values.
Configuration suggestion: If HPA makes an incorrect scaling decision due to fluctuating CPU usage during pod startup, increase the value of this parameter.
Potential risks: A small parameter value may trigger unnecessary scaling based on peak CPU usage, while a large value may cause delayed scaling.
Applicable cluster version: This parameter is available only in clusters v1.23.16-r0, v1.25.11-r0, v1.27.8-r0, v1.28.6-r0, v1.29.2-r0, or later. |
Default: 5 minutes |
Console/API |
|
HPA initial readiness delay |
horizontal-pod-autoscaler-initial-readiness-delay |
Following HPA CPU initialization, this period enables HPA to get CPU metrics with a less strict criterion. During this period, HPA will gather data on the CPU usage of the pods for scaling, regardless of any changes in the pods readiness status. This parameter ensures continuous tracking of CPU usage, even when the pod statuses change frequently.
Configuration suggestion: To prevent HPA misjudgment caused by pod readiness fluctuations after startup, increase the value of this parameter.
Potential risks: If this parameter is set to a small value, an unnecessary scale-out may occur due to CPU data fluctuations when the pod is just ready. If it is set to a large value, the HPA may not respond quickly enough in situations requiring rapid scaling.
Applicable cluster version: This parameter is available only in clusters v1.23.16-r0, v1.25.11-r0, v1.27.8-r0, v1.28.6-r0, v1.29.2-r0, or later. |
Default: 30s |
Console/API |
|
HPA Scale-in Stabilization Window |
horizontal-pod-autoscaler-downscale-stabilization |
Within the stabilization window, the HPA controller continuously observes the recommended scale-in values and selects the maximum recommended replica count. This parameter dampens short-lived load dips, eliminating needless pod churn.
Configuration suggestion: Raise the window to stop rapid scale-in/scale-out caused by transient dips. This improves system stability.
Potential risks: If the stabilization window is too short, HPA will over-react to brief load dips and repeatedly create and delete pods. If it is too long, HPA will keep unneeded pods alive after real demand has dropped, wasting resources. If it exceeds the maximum length supported (153,722,867 minutes), HPA may fail to start. When HPA restarts, the scale-in stabilization timer resets.
Cluster versions: v1.28.15-r60, v1.29.15-r20, v1.30.14-r20, v1.31.10-r20, v1.32.6-r20, v1.33.5-r10, or later |
Default: 5 minutes 0 seconds |
Console/API |
|
QPS for communicating with kube-apiserver |
kube-api-qps |
QPS for communicating with kube-apiserver |
- If the number of nodes in a cluster is less than 1,000, the default value is 100.
- If the number of nodes in a cluster is 1,000 or more, the default value is 200.
|
Console/API |
|
Burst for communicating with kube-apiserver |
kube-api-burst |
Burst QPS for communicating with kube-apiserver. |
- If the number of nodes in a cluster is less than 1,000, the default value is 100.
- If the number of nodes in a cluster is 1,000 or more, the default value is 200.
|
Console/API |
|
Terminated Pods to Be Reclaimed |
terminated-pod-gc-threshold |
Number of terminated pods that can exist in a cluster. When the number of terminated pods exceeds the expected threshold, the excess terminated pods will be automatically deleted.
If this parameter is set to 0, all terminated pods will be retained. |
Default: 1000
Value range: 10 to 12500
If the cluster version is v1.21.11-r40, v1.23.8-r0, v1.25.6-r0, v1.27.3-r0, or later, the value range is changed to 0 to 100000. |
Console/API |
|
Unhealthy AZ threshold |
unhealthy-zone-threshold |
If the number of not-ready nodes exceeds the specified threshold in a given AZ, that AZ will be marked as unhealthy. In such unhealthy AZs, the frequency of service migration for faulty nodes will be reduced to prevent further negative impacts caused by large-scale migrations during major fault scenarios.
Configuration suggestion: Retain the default setting.
Potential risks: If the parameter is set to a large value, pods in unhealthy AZs will be migrated in a large scale, which can lead to risks such as overloading the cluster.
Applicable cluster version: This parameter is available only in clusters v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later. |
Default: 0.55
Value range: 0 to 1 |
Console/API |
|
Node eviction rate |
node-eviction-rate |
The maximum number of pods that can be evicted per second when a node is faulty in a healthy AZ. The default value is 0.1, indicating that pods from at most one node can be evicted every 10 seconds.
Configuration suggestion: Ensure that the number of pods migrated in each batch does not exceed 300. If the parameter is set to a large value, the cluster may be overloaded. Additionally, if too many pods are evicted, they cannot be rescheduled, which will slow down fault recovery.
Applicable cluster version: This parameter is available only in clusters v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later. |
Default: 0.1 |
Console/API |
|
Secondary node eviction rate |
secondary-node-eviction-rate |
The maximum number of pods that can be evicted per second when a node is faulty in an unhealthy AZ. The default value is 0.01, indicating that pods from at most one node can be evicted every 100 seconds.
Configuration suggestion: Configure this parameter to be one-tenth of node-eviction-rate.
Potential risks: For nodes in an unhealthy AZ, there is no need to set this parameter to a large value. Doing so may result in overloaded clusters.
Applicable cluster version: This parameter is available only in clusters v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later. |
Default: 0.01
|
Console/API |
|
Large cluster threshold |
large-cluster-size-threshold |
The criterion for determining whether a cluster is a large-scale cluster. If the number of nodes in a cluster exceeds the value of this parameter, the cluster is considered a large-scale cluster.
Configuration suggestion: For the clusters with a large number of nodes, configure a relatively larger value than the default one for higher performance and faster responses of controllers. Retain the default value for small clusters. Before adjusting the value of this parameter in a production environment, check the impact of the change on cluster performance in a test environment.
Potential risks: In a large-scale cluster, kube-controller-manager adjusts specific configurations to optimize the performance of the cluster. Setting an excessively small threshold for small clusters will deteriorate the cluster performance.
Applicable cluster version: This parameter is available only in clusters v1.23.14-r0, v1.25.9-r0, v1.27.6-r0, v1.28.4-r0, or later. |
Default: 50
|
Console/API |