EKS集群Pod周期性重启排查求助：探针超时与退出码137问题

关于退出码137与默认内存限制 #

退出码137通常对应两种场景：

• 容器进程被系统OOM Killer强制终止（内存占用超过可用资源）
• 容器被外部信号（如SIGKILL）终止（比如kubelet因探针失败触发重启）

在EKS及所有Kubernetes集群中，若Pod未设置resources.limits.memory，默认无容器级内存上限，但Pod内存使用受限于所在节点的总可用内存。当节点内存耗尽时，kubelet会启动OOM Killer，按优先级杀掉内存占用较高的Pod，此时被终止的容器就会出现137退出码。

探针超时与Pod重启的关联 #

从Pod事件来看，就绪/存活探针多次触发context deadline exceeded，说明应用对探针请求的响应超时。结合137退出码，大概率是：

1. 应用内存占用持续升高，导致GC频繁、进程响应变慢，无法在探针timeoutSeconds:5的时限内返回响应
2. 探针失败次数达到failureThreshold:3后，kubelet触发Pod重启（发送SIGKILL），对应退出码137

具体排查步骤 #

• 检查节点内存状态：
  执行kubectl top node查看所有节点的内存使用率，确认是否有节点内存接近耗尽。若节点内存不足，即使Pod未设限制，也会被OOM Killer选中。

• 查看Pod内存使用历史：
  用kubectl top pod <pod-name> --containers实时查看容器内存占用，或通过监控工具（如Prometheus+Grafana）查看内存变化趋势，确认是否存在内存泄漏或突发高峰。

• 检查节点OOM日志：
  登录出现Pod重启的节点，查看dmesg或/var/log/messages，搜索Out of memory或容器ID相关日志，确认是否是OOM Killer终止了容器。示例命令：

  dmesg | grep -i oom
  

• 优化探针配置（临时验证）：
  /users/sign_in登录页面可能依赖数据库、缓存等外部服务，属于较重的检查端点。可临时调整探针：

  • 改用应用内置的轻量健康检查接口（如/healthz，仅返回状态码，不涉及业务逻辑）
  • 延长timeoutSeconds至10，增加failureThreshold至5，减少误判

• 添加内存资源限制：
  即使不确定内存需求，也建议设置resources.requests和resources.limits，既帮助kubelet合理调度Pod到资源充足的节点，也能在内存异常时触发容器级OOM（而非节点级OOM，影响范围更小）。示例配置：

  resources:
    requests:
      memory: "512Mi"
    limits:
      memory: "1Gi"
  

内容的提问来源于stack exchange，提问作者opensource-developer