HPA 按负载缩放 Deployment 的副本
HorizontalPodAutoscaler 是一个反馈控制器，不是容量规划器。每个同步周期（默认 15 秒）它会向 resource metrics API 要一次每 Pod 的 CPU，用观测值除以目标值得到比值，再把结果写进目标工作负载的 scale 子资源。公式只有一行：desiredReplicas = ceil(currentReplicas * currentMetricValue / desiredMetricValue)。 有意思的地方全在限定条件里。控制器会刻意忽略小的比值、刻意推迟缩容，并且在读不到指标或算不出分母时干脆不动。这三种行为是它稳定的原因，也正是为什么一个看起来配置正确的 HPA 会长期停在固定副本数上，而服务在一旁持续超时。 比值与死区 用利用率作目标时，分母不是一个百分比，而是一串毫核数：CPU request 为 200m、目标 60% 的容器，得到的目标指标是 120m。控制器随后把这个比值与 1.0 比较，允许一个可配置的容忍度（默认 0.1），比值落在带内就完全跳过伸缩动作。这条带子不是舍入细节，它就是防抖机制本身。 这条带子让可观测到的行为变得很粗。目标指标 120m 时，平均用量 110m、120m 与 132m 都让副本数原地不动，133m 才是第一个会改变它的值。步进本身是一次向上取整，所以 160m 对 120m 会把三个副本抬到四个，而不是 3.99——Pod 不能是分数，控制器因此永远往容量更充裕的一侧偏。 ...