GKE自动扩缩容中超配公式的两种解读正确性辨析

Great question—this is a super common point of confusion when digging into GKE's autoscaling and over-provisioning logic. Let’s break this down step by step to clear up the contradiction:

First, let’s restate the formula in question:
(1 - buffer) / (1 + traffic)
Where:

• buffer = the CPU utilization buffer percentage (to avoid hitting 100% CPU)
• traffic = expected traffic growth percentage over the next 2-3 minutes

You’ve correctly identified two competing interpretations across GKE documentation:

• First two resources (《Autoscaler and over-provisioning》 & 《Autoscaling with GKE: Clusters and nodes》):
  The result of the formula is the target CPU utilization for HPA. For your example (buffer=15%, traffic=30%):
  (1-0.15)/(1+0.3) ≈ 0.6538 (≈65%)
  This means HPA will aim to keep your Pods running at ~65% CPU utilization. The remaining 35% of capacity per Pod is the over-provisioned buffer—this extra space lets you absorb the expected 30% traffic growth without immediately spinning up new nodes. Cluster Autoscaler/Node Auto-Provisioner only kicks in when this on-node buffer is exhausted and new Pods can’t be scheduled.
• Third manual (《Understanding and Combining GKE Autoscaling Strategies》, 2021):
  This incorrectly frames the 65% result as the percentage of over-provisioned resources to allocate. This flips the formula’s intent entirely.

Let’s unpack the formula’s logic to confirm:

1. (1 - buffer) defines the maximum safe CPU utilization we want to avoid exceeding (85% in your example—this prevents Pods from hitting 100% and experiencing throttling).
2. (1 + traffic) accounts for the expected traffic spike (1.3x in your example).
3. Dividing the max safe utilization by the traffic growth factor gives us the current target utilization we need to maintain. This ensures that when the traffic spike hits, our Pods will reach exactly the max safe utilization (0.65 * 1.3 ≈ 0.845, or ~85%)—using the over-provisioned capacity first before needing to scale nodes.

In short: the formula calculates how much headroom to leave right now so future traffic growth doesn’t immediately push Pods to their limits. The over-provisioned resource percentage is 1 - target utilization (35% in your example), not the target utilization itself.

Your personal view is spot-on: the correct interpretation is that the over-provisioned resource share is 35%, and the formula outputs HPA’s optimized target utilization—not the percentage of extra resources to allocate. The 2021 manual’s interpretation is a clear mix-up of these two values.

内容的提问来源于stack exchange，提问作者Guillermo Ampie