Kubernetes Pod因OOMKilled（退出码137）重启：如何诊断与修复？

Pod被杀死的原因 #

Pod被杀死的直接原因是内存超限（OOMKilled）：你给容器设置的内存硬限制为128Mi，但FastAPI应用启动或运行时实际占用的内存超过了这个阈值，Kubernetes的kubelet组件会强制终止超出内存限制的Pod，进而导致Pod不断重启。

本地非Kubernetes环境运行正常，是因为本地没有对应用的内存使用做强制限制，系统会分配足够的内存给应用，不会触发内存超限的杀死逻辑。

退出码137的含义 #

退出码137由128 + 9组成，其中9对应Linux的SIGKILL信号。这说明进程并非正常退出，而是被外部强制终止——在这里就是kubelet因为内存超限，向Pod内的应用进程发送了SIGKILL信号，直接杀死了进程。

正确设置资源参数的方法 #

1. 确定应用实际内存需求

   • 本地运行应用时，用htop、ps aux --sort=-%mem或FastAPI自带的监控工具查看进程的内存占用峰值；
   • 可临时调高内存限制让Pod正常启动，待运行稳定后用kubectl top pod myapp-6b8f9c7d4b-q5x2t -n myapp查看Pod的实际内存使用情况。

2. 调整资源限制与请求

   • 根据实际内存需求，调高limits.memory的值，例如如果应用实际需要256Mi，可配置：

     resources:
       requests:
         cpu: 200m
         memory: 128Mi
       limits:
         cpu: 500m
         memory: 256Mi
     

   • 建议同时设置requests：requests是Kubernetes调度Pod时的资源需求参考，确保节点有足够资源分配给Pod；limits是硬限制，防止应用无限制占用资源。

3. 排查潜在内存泄漏

   • 如果调大内存限制后，Pod仍会在运行一段时间后被OOMKilled，说明应用可能存在内存泄漏，需要检查代码逻辑（比如未释放的对象、缓存过大等），修复内存泄漏问题。

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