自动扩缩容:3 种策略的适用场景
为什么需要自动扩缩容
API 服务的流量不是恒定的:
- 工作日 vs 周末(白天高、夜间低)
- 营销活动(突发 5-10 倍)
- 日常波动(±20%)
固定容量的问题:
- 容量过小:流量高峰打爆,服务不可用
- 容量过大:闲时浪费,白付钱
自动扩缩容:跟着流量走,既不爆也不浪费。
3 种策略
策略 1:反应式扩缩容 (Reactive)
按当前指标(CPU / 内存 / QPS)决定扩缩容。Kubernetes HPA 默认就是这种。
apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:api-server-hpaspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:api-serverminReplicas:2maxReplicas:20metrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:70优点:实现简单,K8s 原生支持。
缺点:有延迟。流量突增 → CPU 涨 → 触发扩容 → 新 pod 启动(30-60s)→ 接流量。这 30-60s 内服务可能已经被打爆。
适用:流量波动可预测、扩缩容时间窗口够用的场景(日常波动)。
策略 2:预测式扩缩容 (Predictive)
按历史数据预测未来流量,提前扩。K8s 1.18+ 支持(基于 historical metrics)。
# 伪代码defpredict_traffic(history):"""基于过去 7 天的同时段流量,预测未来 1 小时"""now_hour=datetime.now().hour same_hour_last_week=[hforhinhistoryifh["ts"].hour==now_hour]returnmax(same_hour_last_week)*1.2# 加 20% buffer优点:提前扩,避免反应式的延迟。
缺点:预测不一定准。营销活动 / 突发新闻等"反常"流量预测不到。
适用:有规律的业务(电商、新闻、SaaS)。
策略 3:主动式扩缩容 (Scheduled)
按已知时间表(calendar)提前扩。比如每周一早上 9 点开会,8:55 触发扩容。
apiVersion:k8s.alibabacloud.com/v1alpha1kind:CronHPAmetadata:name:cron-hpaspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:api-serverjobs:-name:"scale-up-for-monday-meeting"schedule:"0 8 * * 1"# 每周一 8:00targetSize:10-name:"scale-down-after-meeting"schedule:"30 9 * * 1"# 每周一 9:30targetSize:2优点:完全可控,适合已知规律。
缺点:维护 calendar 麻烦,临时活动要手动加。
适用:明确的业务规律(发布会、营销日、周会)。
混合策略(实战)
实际生产环境一般三种结合:
基础容量(Scheduled): 工作日 9-18: 10 个 pod 周末 / 夜间: 2 个 pod ↓ 触发条件:流量超阈值 ↓ 弹性容量(Reactive): CPU > 70% → 自动加 pod CPU < 30% → 自动减 pod ↓ 触发条件:历史预测异常 ↓ 预测预警(Predictive): 检测到 7 天同时段流量比当前高 50% → 提前扩容效果:既不浪费(基础容量合理),也不爆(弹性扩容 + 预测预警)。
5 个常见坑
1. 冷启动延迟
新 pod 启动 → 加载配置 → 建连接池 → 接流量,通常 30-60s。这段时间流量已经来了,pod 没准备好。
对策:
- Pre-pod 预热:启动时就建好连接池(不等到第一个请求)
- Pod 启动探针:不要等到"ready"才接流量,改成"启动就接"
- HPA 提前扩容:CPU 到 50% 就开始扩,留 buffer
2. 缩容过激
CPU 突然从 80% 掉到 10% → HPA 立刻缩到 2 个 pod → 流量又涨回来 → 又要扩。反复横跳。
对策:
- 缩容冷却时间(K8s 默认 5 分钟,调大到 15 分钟)
- 平滑缩容(每次只缩 1-2 个 pod,不要一次缩一半)
3. 资源请求设错
resources.requests设小了 → K8s 调度时给的资源少 → pod 实际用更多 → 被限流。
对策:
- 压测定 request(不是估,是用 loadtest 测出来)
- 留 30% buffer 给突发
4. 单 region 单可用区
所有 pod 都在一个可用区 → AZ 挂了全挂。
对策:
- podAntiAffinity 强制多 AZ 分布
- 多 region 部署(主 region + 灾备 region)
5. 数据库扛不住
K8s pod 扩到 50 个,但数据库 max_connections 151。50 个 pod × 10 个连接 = 500 个连接,数据库直接拒。
对策:
- 用 PgBouncer / 连接池(100 个 pod 共享 200 个 DB 连接)
- 数据库是瓶颈时,pod 扩再多也没用,要先解决 DB
我们的做法
做 SERP API 时,3 种都用了:
- Scheduled:工作日 9-22 / 周末 10-18 设 4-6 个 pod
- Reactive:CPU > 70% 加 pod,< 30% 减 pod,缩容冷却 10 分钟
- Predictive:每天 18:00 检查明天同时段历史,异常高就提前扩
效果:全年 SLA 99.95%(预算 99.9%),月度成本比固定 6 pod 方案低 25%。
监控指标
| 指标 | 含义 | 告警阈值 |
|---|---|---|
| pod_count | 当前 pod 数 | 接近 maxReplicas |
| cpu_util | 平均 CPU | 持续 > 80% 5 分钟 |
| pending_pods | 等待调度的 pod | > 0 持续 1 分钟 |
| scale_events_per_hour | 扩缩容频率 | > 5 次/小时(横跳) |
| cold_start_latency | 新 pod 首请求耗时 | P99 > 2s |
小结
自动扩缩容没有银弹,3 种策略各有适用场景。生产环境几乎都是混合用:
- Scheduled 管规律
- Reactive 管波动
- Predictive 管趋势
冷启动 + 缩容过激 + 数据库瓶颈是 3 个最常见的坑,提前预防比事后救火好。
SerpBase 实践
SerpBase K8s deployment 混合扩缩容:
- Scheduled:工作日 4-6 pod,周末 2-3 pod
- Reactive:CPU > 70% 加 pod,< 30% 减 pod
- Predictive:每天 18:00 检查明天同时段历史
效果:全年 SLA 99.95%,月度成本比固定 6 pod 方案低 25%。
*本文来自 SerpBase 工程团队。