集群弹性伸缩与容量规划的目标，是让计算资源在业务流量波动时自动匹配需求，避免高峰资源不足、低谷资源浪费。实现这一目标需要同时解决两个问题：一是 Pod 副本数能否随负载变化而增减，二是底层节点能否随 Pod 调度需求快速扩容或回收。前者依赖 Kubernetes 的 HorizontalPodAutoscaler（HPA），后者依赖 Cluster Autoscaler 或云厂商的节点伸缩组。二者配合起来，才能在业务高峰到来前完成容量储备，在低谷期自动回收节点，降低整体资源成本。
本文从组件机制、容量测算、调优策略和成本控制四个角度展开，提供一个可以直接落地的规划框架。
弹性伸缩的核心组件与触发机制
HPA 的工作流程依赖指标采集链路。Metrics Server 负责聚合 Pod 和节点的 CPU、内存等核心资源指标，HPA 控制器每隔固定周期读取这些指标，并将当前观测值与目标值进行比较，计算出期望副本数，再更新 Deployment 或 StatefulSet 的副本字段。举例来说，如果一个 Deployment 的 CPU 目标使用率设置为 60%，当前所有 Pod 的平均 CPU 使用率已经达到 80%，HPA 就会按照公式 期望副本数 = 当前副本数 × 当前使用率 / 目标使用率 进行扩容。实际计算时会向上取整，并受到 minReplicas 和 maxReplicas 的约束。
仅依赖 CPU 和内存指标存在明显局限。CPU 使用率容易受容器限流影响，某些语言运行时也会因为垃圾回收产生周期性波动；内存属于不可压缩资源，一旦分配过高就容易造成节点碎片。更贴合业务的做法是引入自定义指标，例如 QPS、请求延迟、消息队列积压数量等。KEDA 或 Prometheus Adapter 可以把这些业务指标暴露给 HPA，让扩缩容决策更贴近真实流量特征。
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web
minReplicas: 2
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
- type: Resource
resource:
name: memory
target:
type: Utilization
averageUtilization: 70
behavior:
scaleUp:
stabilizationWindowSeconds: 60
policies:
- type: Percent
value: 100
periodSeconds: 60
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Pods
value: 2
periodSeconds: 120
当 HPA 创建出新的 Pod 后，如果节点资源不足，新 Pod 会处于 Pending 状态。Cluster Autoscaler 会监听这些无法调度的 Pod，根据节点池配置向云厂商发起扩容请求。新节点加入集群通常需要一到三分钟，这期间业务流量可能继续上升。因此，容量规划不能只关注 HPA 的反应速度，还必须考虑节点供给延迟。对于秒级突增流量，应当提前准备一定的空闲资源，而不是等到 Pending 出现后再扩容。
业务高峰容量规划的实践步骤
容量规划的第一步是建立单副本基线能力。需要通过压测获取一个 Pod 在真实业务场景下的最大可承载 QPS、平均响应时间以及对应的 CPU 和内存消耗。压测不能只跑简单接口，应覆盖核心业务链路，模拟缓存命中率、数据库连接池占用、消息队列消费速度等关键变量。假设压测结果显示单个 Pod 可以稳定承载 300 QPS，而 CPU 使用率在 55% 左右，那么就可以把单副本承载能力定为 250 QPS，留出一定余量。
第二步是计算业务高峰所需的总副本数。峰值流量通常按历史数据估算，公式为 峰值 QPS = 日常均值 QPS × 峰值系数。峰值系数取决于业务形态，例如电商大促可能是日常的 5 到 10 倍，金融结算窗口可能是 3 倍。得到峰值 QPS 后，再用 总副本数 = 峰值 QPS / 单副本承载 QPS × 安全冗余系数 计算。安全冗余系数一般取 1.2 到 1.5，用于吸收压测误差和流量毛刺。节点数量则通过 总 CPU 请求 / 单节点可分配 CPU 计算，同时要考虑系统组件、DaemonSet 和节点预留的资源。
第三步是把容量测算结果映射到弹性伸缩参数。HPA 的 minReplicas 应设置为日常基线所需副本数，例如 4 个副本；maxReplicas 设置为高峰所需副本数的 1.2 倍，例如 24 个副本。这样既保证低谷期不会保留过多 Pod，又能在高峰到来时快速扩展。节点伸缩组的最小节点数应覆盖基线副本的调度需求，最大节点数则根据峰值副本数和单节点 Pod 密度来设定，同时为节点扩容预留缓冲时间。
自动扩缩容的常见陷阱与调优策略
最常见的误区是把 CPU 目标值设得过高，例如 80% 甚至 90%。这种配置看似节省资源，实际上会让 Pod 在流量上升阶段过早进入 CPU 限流状态，导致响应延迟增加，甚至触发健康检查失败。推荐将 CPU 目标使用率设置在 50% 到 65% 之间，同时结合内存目标和自定义业务指标共同决策。多指标 HPA 会取所有指标计算出的副本数最大值，因此可以防止单一指标失真造成扩容不足。
另一个容易忽视的问题是缩容过于激进。HPA 默认的缩容冷却时间较短，某些场景下会频繁创建和销毁 Pod，导致请求被中断、连接池反复重建。通过 behavior 字段可以分别控制扩缩容策略。建议给缩容设置更长的稳定窗口，例如 5 分钟，并限制单次缩容的 Pod 数量，避免短时间流量波动导致误缩容。扩容策略则可以适当激进，让扩容在 1 分钟内完成，以快速响应流量增长。
节点扩容延迟可以通过预留占位 Pod 的方式缓解。创建一批低优先级、低资源占用的 Pause Pod，并设置 PriorityClass 为低优先级。当突发流量到来时，真正的业务 Pod 会抢占这些占位 Pod，触发调度压力，Cluster Autoscaler 会提前扩容节点。占位 Pod 被驱逐后，新节点已经加入集群，业务 Pod 可以直接调度。这个方案相当于用少量资源换取节点预热时间。
apiVersion: apps/v1
kind: Deployment
metadata:
name: overprovisioning
spec:
replicas: 2
selector:
matchLabels:
app: overprovisioning
template:
metadata:
labels:
app: overprovisioning
spec:
priorityClassName: low-priority
containers:
- name: pause
image: registry.k8s.io/pause:3.9
resources:
requests:
cpu: 500m
memory: 512Mi
还需要关注节点缩容策略。Cluster Autoscaler 默认会把空闲节点缩掉，但如果缩容速度过快，可能导致频繁扩缩。可以调整 scale-down-utilization-threshold、scale-down-unneeded-time 等参数，让节点在持续低利用率一段时间后才被回收，避免因为短期低谷就缩掉节点，随后流量回升又需要重新扩容。
成本控制与容量预留的平衡
弹性伸缩的主要收益是成本优化，但过度预留会侵蚀收益。固定集群在低峰期仍要支付全部节点费用，而弹性集群可以在低峰期缩容到最低节点数。要实现成本可控，需要为不同工作负载设置不同的节点池。核心业务使用按量付费或包年包月的稳定节点，突发计算任务使用 Spot 实例或抢占式节点，通过节点标签和污点控制 Pod 调度范围。这样可以在保证稳定性的同时，把高峰期的增量成本大幅降低。
容量预留的粒度也需要精细化。不要为一个集群整体预留大块资源，而是按命名空间、业务线或资源配额进行划分。ResourceQuota 可以限制每个命名空间可申请的 CPU、内存和存储总量，LimitRange 则为 Pod 设置默认请求和上限。合理的配额设计可以防止单个业务过度占用资源，影响其他业务的弹性伸缩效果。节点池还可以配置不同规格，例如高配节点用于数据库类任务，低配节点用于无状态 Web 服务，提高整体资源利用率。
成本分析是容量规划的闭环环节。建议定期对比实际使用量与申请量的差距，计算公式为 资源利用率 = 实际使用量 / 申请量。如果申请量长期远高于使用量，说明 Pod 的 requests 设置过大，需要下调并重新评估 HPA 参数；如果节点分配率长期偏低，说明节点规格或节点池配置不合理。通过持续优化 requests、limits、节点规格和扩缩容参数，才能在高峰容量保障和低峰成本控制之间找到稳定的平衡点。
集群弹性伸缩与业务高峰容量规划不是一次性配置，而是一个持续迭代的过程。业务模型变化、依赖服务性能波动、节点硬件代际升级都会影响容量测算结果。建议在每个大促或业务高峰前重新执行压测和容量评估，高峰结束后复盘扩缩容事件，找到扩容慢、缩容过激或资源浪费的根因，逐步把集群建设成能够自动适应流量变化的弹性基础设施。