K8s 弹性伸缩踩坑实录：周末 2 天烧掉 10 万元！？

01/

令人措手不及的告警

那是一个周日的早晨，我正刷着牙，手机却突然开始疯狂震动：

Slack 告警（来自 AWS）：

“您本月的支出已超过预算的 80%。”

财务团队紧急消息：

 “今天早上 AWS 为什么一下子扣了我们 $5,000？”

原来，原本应该“智能”的 Kubernetes 弹性伸缩彻底失控了。

本以为只是周五下午随手改了个小配置，结果这个通常只需 3 个 Pod 的服务，竟然疯狂扩容了 87 个副本——烧钱速度比拉斯维加斯的赌场还快。

02/

问题是怎么发生的？

我们一直在稳定运行一个处理后台任务的 Java 服务，几个月来相安无事...直到我们试图对它进行"优化"。

乍看之下，我们的 HorizontalPodAutoscaler 配置似乎很合理：

apiVersion: autoscaling/v2kind: HorizontalPodAutoscalerspec:  maxReplicas: 100    metrics:  - type: Resource    resource:      name: cpu      target:        averageUtilization: 50  

• 我们期望的效果：「根据 CPU 使用率，在 2-20 个 Pod 之间优雅弹性伸缩」

• 实际发生的情况：「给我往死里扩！」

我们在配置伸缩策略时，完全没有设置任何保护措施，留下了多个隐患：

• 没有设置 PodDisruptionBudget：

  缩容时 Kubernetes 会直接无差别地删除 Pod，场面堪比《权力的游戏》的大清洗

• 缺失 AWS 费用告警：

  最先发现问题的居然是财务部，而不是监控系统

• 错误指标：

  CPU 使用率根本不适合作为该工作负载的伸缩依据

03/

我们是如何排查问题的？

在执行 kubectl top pods 后，我们看到：

NAME                          CPU(cores)  worker-service-abc123         5m          # Basically idle  worker-service-def456         7m  ... (87 more lines of this nonsense)

经过排查，我们发现：

• 我们的 Java 服务在运行过程中偶尔会有 GC 带来短暂的 CPU 峰值

• HPA 误将这些瞬时波动识别为“资源告急”，随即触发扩容

• 每新增一个 Pod，又会引入更多 GC 活动，进而造成更频繁的峰值

• 形成一个“波动—扩容—更多波动”的反馈循环

结果就是在短时间内，大量资源被毫无必要地调度出来，成本极速上升。

04/

如何解决问题？

针对这个队列处理服务，改用 Kafka 消息积压数作为核心指标：

metrics:- type: External  # Now scales based on actual work  external:    metric:      name: kafka_messages_behind      target:      averageValue: 1000

maxReplicas: 10  # Hard ceiling  minReplicas: 1   # Let it breathe

• AWS预算警报：消费每增加 $500 即触发邮件 + Slack 双重告警

• 优化 Cluster Autoscaler 参数：

--scale-down-unneeded-time=15m            # 避免太快回收节点  --skip-nodes-with-local-storage=true      # 避免误删有状态节点

05/

我们的经验教训

这次代价昂贵的事故，让我们团队总结出了几条核心教训：

• 自动伸缩并非“配置一次就万事大吉”，它需要持续关注和调整，更像是一只宠物而不是牛群；

• 不要在周五下班前部署敏感改动，伸缩类改动建议放在工作日早上；

• 财务团队是很灵敏的告警系统，虽然他们收到账单时不会给你好脸色

在部署 HPA 配置更改前，强烈建议先运行以下命令，实时观察变化：

kubectl get hpa -w

比起事后看到账单崩溃，实时观察指标的跳动会更有安全感。

推荐阅读

揭秘 Anthropic 如何降低 Claude 模型的训练与推理成本

弹性伸缩从可用到好用，中间差了这 8 个关键点——CloudPilot AI 如何补齐？

Grafana 实操：打造全面的 K8s 资源监控仪表盘