EKS集群EC2实例Pod耗尽后无响应，ASG未触发扩容问题排查

1. 先确认ASG扩容触发逻辑是否正常 #

• 检查CloudWatch指标采集状态：实例状态变为Unknown时，大概率kubelet已经无法和EKS API Server通信，同时CloudWatch Agent可能也停止上报指标。ASG依赖有效指标判断是否扩容，如果CPU使用率数据中断，告警不会触发。去CloudWatch控制台查看该实例的CPU使用率曲线，确认在实例异常后是否还有数据上报。
• 核对ASG扩容配置细节：
  • 检查ASG的最大实例数是否大于当前实例数，比如如果最大设为1，自然无法扩容。
  • 查看ASG的冷却时间（Cooldown），如果冷却时间过长，即使满足阈值也会延迟扩容。
  • 确认告警规则的触发条件是否正确：比如是不是设置了“连续N个周期超过70%”，而实例在触发前就已经挂了，没达到连续周期的要求。

2. 实例无响应的核心原因：资源过载 #

t3.medium实例（2vCPU/4Gi内存）跑17个Selenium Chrome Pod，明显资源过载：

• 检查Pod的资源请求（resources.requests）和限制（resources.limits）配置：如果request设置过低（比如CPU request设为0.1），K8s调度器会认为节点能容纳更多Pod，但实际运行时Chrome会占用大量CPU/内存，直接把节点打满，导致kubelet崩溃、节点失联。
• 查看节点历史日志：如果能获取到节点崩溃前的kubelet日志，会看到Out of memory或CPU throttling相关报错，OOM Killer可能已经触发杀掉进程，最终导致节点状态变为Unknown。

3. HPA与ASG联动的问题 #

• 确认Cluster Autoscaler（CA）是否正常工作：EKS的ASG扩容依赖CA，要检查：
  • CA是否正确部署，且拥有访问ASG的IAM权限。
  • ASG是否添加了正确的标签（比如k8s.io/cluster-autoscaler/<集群名>），确保CA能识别到该ASG。
• 当前场景下，HPA扩容的17个Pod都成功调度到了节点上（虽然节点撑爆了），没有Pending Pod，CA不会触发扩容——CA的核心逻辑是当有Pending Pod无法调度时才会扩容节点。这说明Pod的资源request设置不合理，导致调度误判。

4. 临时修复与优化建议 #

• 调整Pod资源配置：给每个Chrome Pod设置合理的资源请求，比如：

  resources:
    requests:
      cpu: "0.3"
      memory: "768Mi"
    limits:
      cpu: "0.5"
      memory: "1Gi"
  

  这样t3.medium最多能运行6个左右Pod，避免节点一次性过载。
• 更换ASG扩容触发逻辑：放弃基于EC2 CPU使用率的告警，改用CA的pending_pods指标触发ASG扩容，这样当HPA扩容出的Pod无法调度时，直接触发节点扩容，比依赖节点指标更可靠。
• 增加实例类型或调整最大Pod数：如果需要单节点运行更多Pod，可以考虑升级到t3.large，或者调整节点的kubelet配置增加最大Pod数（注意网络插件的Pod CIDR限制）。

内容的提问来源于stack exchange，提问作者Sanjay Bhatia