DevEx开发者体验工程 - 第2节
2. 弹性伸缩基础
弹性伸缩是平台工程中保障服务稳定性与成本效率的核心能力。在 Kubernetes 生态中，弹性伸缩主要分为两种模式：水平扩展（Scale Out/In） 与 垂直扩展（Scale Up/Down）。理解两者的差异与适用场景，是编排弹性伸缩运营任务的前提。
水平扩展 vs 垂直扩展
| 维度 | 水平扩展（Horizontal） | 垂直扩展（Vertical） |
|---|---|---|
| 操作对象 | 增加/减少 Pod 副本数量 | 调整单个 Pod 的 CPU/内存资源请求与限制 |
| 伸缩粒度 | 整副本（Pod） | 资源量（mCPU/MiB） |
| 响应速度 | 中等（需调度与拉取镜像） | 较快（原地更新资源字段） |
| 适用场景 | 无状态服务、突发流量、微服务 | 有状态服务、单体应用、资源利用率优化 |
| K8s 控制器 | HorizontalPodAutoscaler（HPA） | VerticalPodAutoscaler（VPA） |
| 典型限制 | 需负载均衡器支持；有状态应用迁移成本高 | 受单节点资源上限约束；需重启 Pod |
平台工程建议： 在编排运营任务时，优先为无状态工作负载配置 HPA，为有状态或资源敏感型工作负载配置 VPA。两者可组合使用，但需避免策略冲突（例如 VPA 与 HPA 基于同一指标竞争）。
弹性伸缩的触发条件与策略
弹性伸缩并非盲目扩缩，而是基于明确的触发条件与策略规则。常见的触发条件包括：
- 资源指标： CPU 利用率、内存利用率（Kubernetes 内置指标）。
- 自定义指标： QPS、请求延迟 P99、队列深度（需 Prometheus Adapter 或 Custom Metrics API）。
- 外部指标： 消息队列积压数、数据库连接数（需 External Metrics API）。
- 时间策略： 基于 Cron 表达式预定义扩缩窗口（如促销活动前扩容）。
策略规则决定了伸缩的速率、边界与行为：
| 策略参数 | 说明 | 示例值 |
|---|---|---|
minReplicas |
最小副本数，保障基础容量 | 2 |
maxReplicas |
最大副本数，防止资源耗尽 | 20 |
targetCPUUtilizationPercentage |
目标 CPU 利用率，触发扩缩的基准 | 70% |
behavior.scaleUp.stabilizationWindowSeconds |
扩容稳定窗口，避免指标抖动导致频繁扩容 | 60 |
behavior.scaleDown.selectPolicy |
缩容策略（优先选择最浪费/最旧 Pod） | MinChange |
运营任务编排要点： 在平台工程中，应将触发条件与策略参数化，通过 ConfigMap 或 CRD 暴露给开发者，避免硬编码。同时，需在伸缩任务中嵌入“冷却期”与“稳定窗口”逻辑，防止震荡。
Kubernetes HPA 与 VPA 原理
HPA（HorizontalPodAutoscaler）工作原理
HPA 是一个控制循环组件，由 kube-controller-manager 负责执行。其核心流程如下：
- 指标采集： HPA 控制器通过 Metrics API（Resource Metrics 或 Custom Metrics）获取目标工作负载的当前指标值。
- 期望副本计算： 使用公式
desiredReplicas = ceil[currentReplicas × (currentMetricValue / targetMetricValue)]计算期望副本数。 - 策略校验： 将期望副本数限制在
minReplicas与maxReplicas之间，并应用behavior策略（如稳定窗口、速率限制）。 - 更新工作负载： 修改目标 Deployment/StatefulSet 的
spec.replicas字段，触发控制器更新 Pod 数量。
常见陷阱： 如果目标工作负载的 Pod 未定义
resources.requests，HPA 将无法计算 CPU/内存利用率，导致伸缩失效。平台工程应在开发者创建 HPA 时强制校验资源请求字段。
VPA（VerticalPodAutoscaler）工作原理
VPA 通过分析 Pod 的历史资源使用数据，推荐或自动调整 Pod 的 CPU/内存请求与限制。VPA 包含三个核心组件：
- Recommender： 基于历史指标（默认 8 天窗口）计算推荐资源值，支持百分位策略（如 P95）。
- Updater： 当推荐值与当前值偏差超过阈值时，驱逐 Pod 并触发重建，使新 Pod 使用推荐资源。
- Admission Controller： 在 Pod 创建时注入 VPA 推荐的资源值，确保新 Pod 直接使用优化配置。
| VPA 模式 | 行为 | 适用场景 |
|---|---|---|
Off |
仅提供推荐值，不自动调整 | 审计与容量规划 |
Initial |
仅在 Pod 创建时注入推荐值 | 避免运行时驱逐，适合无中断要求的工作负载 |
Auto |
自动驱逐并重建 Pod 以应用新资源 | 资源利用率优化，可接受短暂重启 |
Recreate |
与 Auto 类似，但始终通过重建方式更新 | 需要确保资源变更生效的场景 |
平台工程最佳实践： 在非生产环境使用
Auto 模式验证 VPA 效果；生产环境建议先使用 Off 模式观察推荐值，确认合理后再切换为 Initial 模式，避免频繁驱逐影响可用性。
HPA 与 VPA 的协同与冲突
在平台工程中，HPA 与 VPA 可以共存，但需遵循以下规则避免冲突：
- 避免基于相同指标竞争： 如果 HPA 基于 CPU 利用率伸缩，VPA 也调整 CPU 请求，两者会相互干扰。建议 HPA 使用自定义指标（如 QPS），VPA 仅调整内存。
- VPA 更新后重置 HPA 目标： VPA 调整 Pod 资源请求后，HPA 的利用率计算基准会变化，可能导致 HPA 误判。平台应监控并记录此类变更。
- 推荐组合模式： 使用 VPA 的
Initial模式为 Pod 设置合理的初始资源，再通过 HPA 的Auto模式应对流量波动。
运营任务编排清单：
✅ 为每个工作负载明确伸缩模式（HPA / VPA / 组合）
✅ 配置指标采集与聚合管道（Prometheus + Metrics Adapter）
✅ 设置伸缩边界（min/max）与稳定窗口，防止震荡
✅ 记录每次伸缩事件到审计日志，用于事后分析
✅ 定期验证 VPA 推荐值与实际负载的匹配度
✅ 为每个工作负载明确伸缩模式（HPA / VPA / 组合）
✅ 配置指标采集与聚合管道（Prometheus + Metrics Adapter）
✅ 设置伸缩边界（min/max）与稳定窗口，防止震荡
✅ 记录每次伸缩事件到审计日志，用于事后分析
✅ 定期验证 VPA 推荐值与实际负载的匹配度