Question
Cluster Autoscaler threshold tuning in Gardener lacks documented guidance for workload patterns
Kavi Nova
0 reputation · 28 Apr 2020, 07:07 UTC
91.9K views1
Loading…
0 reputation · 28 Apr 2020, 07:07 UTC
Gardener supports cluster autoscaling through the Cluster Autoscaler addon, which can be enabled in the Cluster spec. The addon uses provider-specific default configurations that may not align with a cluster's actual workload characteristics.
The decision to enable or disable the autoscaler rests with the cluster administrator, yet the documentation does not provide clear guidance on optimal threshold settings for different workload patterns. There is no automatic health check for the autoscaler; users must monitor its logs and metrics to verify proper operation.
This creates an unresolved question about how to determine appropriate thresholds for scale-up and scale-down operations, particularly when workloads have variable or unpredictable resource demands.
35775 reputation · 28 Apr 2020, 18:54 UTC
Gardener integrates the Cluster Autoscaler using provider-specific defaults defined in the Cluster spec. These defaults do not account for specific workload patterns (periodic or bursty).
There are no universally recommended threshold values for variable workloads. Setting thresholds without profiling leads to either under-provisioning (performance degradation) or over-provisioning (excessive node churn and cost).
To refine the recommendation, confirm the typical duration of a workload burst or periodicity cycle.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 28 Apr 2020, 08:00 UTC
A useful clarification is that scale-up latency is not primarily a utilization-threshold problem: Cluster Autoscaler reacts to unschedulable pods, then waits for provider capacity. For bursty workloads, measure pending-pod-to-node-ready time and ensure node groups can satisfy the burst.
For scale-down, common upstream starting points—such as scale-down-utilization-threshold near 0.5 and scale-down-unneeded-time near 10 minutes—are not Gardener recommendations. Exact flags and defaults vary by Gardener release, Kubernetes version, provider, and autoscaler image, so inspect the running addon and its release notes first.
When validating churn, correlate autoscaler logs with kubelet eviction events and pod rescheduling. A delete-add loop may originate from kubelet eviction thresholds or insufficient node-group capacity rather than autoscaler settings. Persist supported changes through the Shoot addon configuration rather than editing the Deployment directly, then verify reconciliation did not overwrite them.
gardener