2. HPA 与 Kubernetes 架构：HPA 在 K8s 控制平面中的位置、与 Deployment/StatefulSet 的关系、资源请求与限制的关联
2.1 HPA 在控制平面中的位置
HPA（Horizontal Pod Autoscaler）是 Kubernetes 控制平面中负责自动水平扩缩 Pod 副本数的核心控制器。它位于 kube-controller-manager 内部，以控制循环（Control Loop）的方式运行，默认每 15 秒（由 --horizontal-pod-autoscaler-sync-period 控制）评估一次指标并调整副本数。
关键路径： HPA 控制器 → Metrics Server（或自定义指标 API）→ 目标资源（Deployment/StatefulSet）→ ReplicaSet → Pod。
HPA 不直接管理 Pod，而是通过修改目标资源的 spec.replicas 字段来触发扩缩容。控制平面中的完整链路如下：
2.2 HPA 与 Deployment / StatefulSet 的关系
HPA 通过 scale 子资源与目标工作负载交互。Deployment 和 StatefulSet 都实现了 Scale 接口，因此 HPA 可以统一操作两者。但两者在扩缩容行为上存在关键差异：
| 对比维度 | Deployment | StatefulSet |
|---|---|---|
| 底层控制器 | ReplicaSet | StatefulSet 自身（Pod 有序编号） |
| Pod 标识 | 随机名称，无状态 | 固定序号（如 web-0, web-1），有状态 |
| 扩缩容顺序 | 并行创建/删除 | 缩容时逆序删除（从最大序号开始），扩容时顺序创建 |
| HPA 适用场景 | 无状态应用（Web、API、微服务） | 有状态应用（数据库、消息队列、缓存） |
| 缩容风险 | 低（Pod 无状态，可随时替换） | 高（需确保数据迁移或优雅关闭） |
实践警告： 对 StatefulSet 使用 HPA 时，务必配合
PodDisruptionBudget（PDB）防止同时缩容过多有状态 Pod。同时建议设置 behavior.scaleDown.stabilizationWindowSeconds 避免频繁缩容导致数据迁移风暴。
2.3 资源请求与限制的关联
HPA 的指标计算与 Pod 的 resources.requests 和 resources.limits 有直接关联。理解这一关联是正确配置 HPA 的前提：
- CPU 指标： HPA 使用
requests作为基准值。例如目标利用率 80% 意味着：当前 CPU 使用量 / Pod 的 CPU request达到 0.8 时触发扩容。 - 内存指标： 同样基于
requests计算。但内存使用量不会自动下降（除非进程释放），因此内存 HPA 通常需要配合behavior策略防止抖动。 - 自定义指标： 不依赖
requests/limits，直接使用指标值（如 QPS、连接数）。
2.4 关键配置参数对比
| 参数 | 作用 | 推荐值 | 与资源请求的关联 |
|---|---|---|---|
targetCPUUtilizationPercentage |
CPU 目标利用率 | 50% ~ 80% | 基于 requests.cpu 计算 |
targetMemoryUtilizationPercentage |
内存目标利用率 | 50% ~ 70% | 基于 requests.memory 计算 |
behavior.scaleUp.stabilizationWindowSeconds |
扩容稳定窗口 | 0 ~ 60s | 无直接关联，但影响扩缩响应速度 |
behavior.scaleDown.stabilizationWindowSeconds |
缩容稳定窗口 | 60 ~ 300s | 建议有状态应用设置较大值 |
--horizontal-pod-autoscaler-sync-period |
HPA 评估周期 | 15s（默认） | 无直接关联 |
最佳实践： 始终为工作负载设置合理的
requests 值。如果 requests 设置过高（如接近 limits），HPA 将难以触发扩容；如果设置过低，HPA 可能过早扩容导致资源浪费。建议通过 Vertical Pod Autoscaler（VPA）或历史监控数据校准 requests 基线。
2.5 资源限制对 HPA 的间接影响
虽然 HPA 不直接读取 limits，但 limits 通过以下方式间接影响 HPA 行为：
- CPU Throttling： 当 Pod 实际使用超过
limits.cpu时，CPU 被限流（Throttle），导致指标下降，可能使 HPA 误判为负载降低而缩容。 - OOM Kill： 当 Pod 内存使用超过
limits.memory时，Pod 被 OOM Kill，HPA 检测到 Pod 消失后可能触发扩容，形成“OOM → 扩容 → 新 Pod 再 OOM”的恶性循环。 - QoS 等级：
requests与limits的关系决定了 Pod 的 QoS 等级（Guaranteed / Burstable / BestEffort），影响调度优先级和驱逐顺序，间接影响 HPA 的稳定性。
避坑指南： 对于 HPA 管理的 Pod，建议设置
limits 为 requests 的 1.2~2 倍（Burstable QoS），避免 CPU Throttling 干扰 HPA 判断。同时确保 limits.memory 足够容纳应用峰值内存，防止 OOM 导致 HPA 震荡。