Kubernetes Pod频繁因退出码137终止重启求助

退出码137对应SIGKILL信号，说明Pod被系统强制终止。结合你的场景（节点2CPU/4G，设置CPU limit为2核后恢复），核心问题大概率和节点资源分配、Pod QoS等级或集群组件资源占用有关，以下是具体排查和解决步骤：

1. 检查节点实际可分配CPU #

每个节点标称2核，但K8s会预留部分资源给系统组件（kubelet、containerd、操作系统进程），实际可分配给Pod的CPU可能远低于2核。执行命令查看节点可分配资源：

kubectl describe node <你的节点名> | grep -A5 "Allocatable"

如果可分配CPU低于你的Pod CPU limit（1核），说明节点无法稳定满足Pod的资源限制，当CPU负载波动时会触发驱逐。

• 解决：调整kubelet的--kube-reserved和--system-reserved参数，减少系统资源预留；或者清理节点上其他高CPU占用的Pod/进程。

2. 调整Pod的QoS等级 #

你的Pod当前是Burstable等级（request≠limit），在节点资源紧张时会被优先驱逐。如果把CPU的request和limit设为相同值（比如都设为500m），Pod会变为Guaranteed等级，kubelet不会优先终止这类Pod，同时也不会占用过多资源：

apiVersion: v1
kind: Pod
metadata:
  name: alpine
  namespace: default
spec:
  containers:
  - image: alpine
    resources:
      requests:
        cpu: 500m
        memory: 256Mi
      limits:
        cpu: 500m  # 和request保持一致，提升QoS等级
        memory: 256Mi
    command:
      - /bin/sh
      - "-c"
      - "sleep 60m"
    imagePullPolicy: IfNotPresent
    name: alpine
    securityContext:
      allowPrivilegeEscalation: true
  restartPolicy: Always

3. 排查节点CPU占用情况 #

即使你的Pod是sleep进程，节点上的其他进程（比如kubelet、containerd、其他业务Pod）可能突发高CPU占用，导致节点CPU使用率拉满触发驱逐。

• 在节点上执行top查看实时CPU占用；
• 或通过metrics-server查看节点指标：

  kubectl top node
  

如果发现异常高占用的进程，针对性优化（比如升级组件、关闭无用进程、调整其他Pod的资源限制）。

4. 检查容器运行时异常 #

Pod事件中出现SandboxChanged，说明容器沙箱（containerd组件）发生异常导致Pod重建。查看containerd日志排查问题：

journalctl -u containerd -f

如果是版本兼容问题（K8s v1.28要求containerd≥1.6.0），升级containerd到适配版本即可。

5. 调整kubelet驱逐阈值 #

kubelet默认的资源驱逐阈值如果过于严格，会在节点资源小幅波动时触发驱逐。查看kubelet配置：

cat /var/lib/kubelet/config.yaml | grep evictionHard

比如memory.available: 100Mi这类阈值如果过低，可调整为更宽松的值（如200Mi），避免误触发。

为什么Docker Desktop中运行正常？ #

Docker Desktop的资源管理逻辑和K8s集群不同：它没有K8s的QoS等级划分和节点驱逐机制，默认给容器的资源限制更宽松，因此不会出现类似的强制终止问题。

内容的提问来源于stack exchange，提问作者Cleriston Martins Cardoso