弹性伸缩基础：定义、核心价值与常见触发策略
弹性伸缩（Auto Scaling）是云原生架构中实现按需分配资源的核心能力。它允许系统根据实时负载自动增加或减少计算资源，从而在保证服务质量的同时优化成本。本章将系统梳理弹性伸缩的定义、核心价值以及最常见的触发策略，为后续章节中结合健康检查与门禁规则进行发布控制奠定基础。
2.1 弹性伸缩的定义
弹性伸缩是指通过预设的规则或算法，自动调整应用或服务的实例数量（或资源规格），使其能够动态匹配当前业务负载的过程。在 Kubernetes 生态中，弹性伸缩通常表现为以下两种形式：
- 水平伸缩（Horizontal Scaling）：增加或减少 Pod 副本数量，是云原生中最常用的弹性方式。
- 垂直伸缩（Vertical Scaling）：调整单个 Pod 的 CPU/内存资源请求与限制，通常用于有状态服务或无法水平扩展的组件。
关键概念：弹性伸缩不是简单的“扩容/缩容”，而是一个闭环控制系统。它包含指标采集 → 决策评估 → 执行调整 → 稳定观察四个阶段。健康检查与门禁规则正是在“执行调整”和“稳定观察”阶段介入，确保伸缩动作不会破坏系统稳定性。
2.2 核心价值：成本与可用性
弹性伸缩的价值可以归纳为两个核心维度：成本优化与可用性保障。两者并非对立，而是通过精准的伸缩策略实现平衡。
| 维度 | 目标 | 实现方式 | 典型场景 |
|---|---|---|---|
| 成本优化 | 避免资源闲置浪费 | 低峰期缩容至最小副本数，释放空闲资源 | 夜间业务低谷、周末非工作时间 |
| 可用性保障 | 应对突发流量，避免过载 | 高峰期快速扩容，维持响应时间与错误率在阈值内 | 秒杀活动、热点事件、突增的 API 调用 |
| 平衡点 | 以最小资源满足 SLA | 设置合理的扩缩容阈值与冷却时间，避免频繁抖动 | 日常业务波动、周期性流量 |
实践要点：在质量门禁体系中，弹性伸缩的“可用性”维度需要与健康检查深度绑定。例如，扩容时新实例必须通过启动探针（Startup Probe）和就绪探针（Readiness Probe）后才能接入流量；缩容时需确保正在处理的请求完成（优雅终止），避免连接中断。
2.3 常见触发策略
弹性伸缩的触发策略决定了“何时伸缩”以及“伸缩多少”。以下是生产环境中最常用的三种策略：
2.3.1 基于 CPU 使用率
- 原理：监控 Pod 的平均 CPU 使用率（相对于 Request），当超过/低于目标值时触发扩容/缩容。
- 优点：指标成熟、采集成本低、Kubernetes 原生支持（HPA）。
- 缺点：对 CPU 密集型应用敏感，但对内存型、IO 密集型或异步处理型应用反应滞后。
- 典型配置：目标 CPU 使用率 50%~80%，冷却时间 3~5 分钟。
2.3.2 基于内存使用率
- 原理：监控 Pod 的平均内存使用率（相对于 Request），当超过/低于目标值时触发伸缩。
- 优点：适合内存密集型应用（如缓存、数据处理）。
- 缺点：内存回收机制（GC）可能导致指标抖动；内存使用率上升通常比 CPU 慢，响应不够及时。
- 典型配置：目标内存使用率 60%~80%，配合 CPU 策略组合使用。
2.3.3 基于请求量（QPS/RPS）
- 原理：通过 Service Mesh、Ingress 或应用侧指标采集每秒请求数（QPS），当请求量超过单 Pod 承载上限时扩容。
- 优点：直接反映业务负载，比 CPU/内存更精准；适合 Web 服务、API 网关等流量驱动型应用。
- 缺点：需要额外指标采集与暴露（如 Prometheus + Custom Metrics API），配置复杂度较高。
- 典型配置：单 Pod 目标 QPS = 500，扩容阈值 = 当前 QPS / 500 > 当前副本数。
避坑提示：不要只依赖单一指标。例如，基于 CPU 扩容时，如果应用因死循环导致 CPU 飙升，扩容反而会加剧问题。建议将 CPU/内存与业务指标（如请求延迟、错误率）组合使用，并在门禁规则中加入健康检查前置条件。
2.4 策略组合与最佳实践
单一策略往往无法覆盖所有场景。生产环境推荐采用多指标组合策略，并配合弹性伸缩门禁来提升安全性：
- CPU + 内存组合：避免因单一指标抖动导致误伸缩。例如，只有当 CPU > 70% 且 内存 > 60% 时才触发扩容。
- QPS + 延迟组合：当请求量上升但延迟仍在正常范围时，可暂缓扩容；当延迟也超过阈值时立即扩容。
- 冷却时间与稳定窗口：扩容后设置 3~5 分钟冷却时间，缩容后设置 5~10 分钟稳定窗口，防止频繁震荡。
- 门禁前置检查：在伸缩动作执行前，检查当前集群健康状态（如节点资源、控制面负载），避免在集群不稳定时触发大规模伸缩。
质量门禁关联：在弹性伸缩发布过程中，健康检查是门禁规则的第一道防线。新扩容的 Pod 必须通过启动探针（确认进程已启动）和就绪探针（确认服务可正常处理请求）后，才能被纳入 Service 端点列表。缩容时，PreStop Hook 确保正在处理的请求完成后再移除 Pod。这些门禁规则将在后续章节中详细展开。