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

01｜令人措手不及的告警

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

Slack 告警（来自 AWS ）：

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

财务团队紧急消息：

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

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

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

02｜问题是怎么发生的？

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

失误一：过度自信的HPA配置

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

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    spec:
      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｜如何解决问题？

✅ 1. 停止使用 CPU 作为依据指标

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

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

✅ 2. 设定合理的伸缩上下限

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

✅ 3. 引入成本控制与弹性策略

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

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

05｜我们的经验教训

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

1. 自动伸缩并非“配置一次就万事大吉”， 它需要持续关注和调整，更像是一只宠物而不是牛群；
2. 不要在周五下班前部署敏感改动，伸缩类改动建议放在工作日早上；
3. 财务团队是很灵敏的告警系统，虽然他们收到账单时不会给你好脸色

💡 实用小贴士：

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

    kubectl get hpa -w

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