AKS集群Pod出现ContainerStatusUnknown（退出码137）问题求助

一、是否与OOM相关？ #

Exit Code 137是容器进程被强制终止（SIGKILL信号）的典型标识，OOM（内存不足）是最常见的触发原因：当容器内存使用超出配置的resources.limits.memory，或节点剩余内存不足以支撑所有运行Pod时，kubelet会启动OOM Killer终止高内存占用进程，导致容器异常退出。此外，节点意外重启也会导致容器状态丢失，出现ContainerStatusUnknown和无法获取日志的情况。

二、排查与解决步骤 #

1. 检查节点资源占用 #

先确认节点是否存在资源耗尽情况：

kubectl top nodes

若节点内存使用率接近100%，说明节点资源不足。此时若AKS自动扩缩容未触发（可能受冷却时间、配额限制影响），可手动调整节点池规模：

az aks nodepool scale --resource-group <你的资源组名> --cluster-name <AKS集群名> --name <节点池名称> --node-count <目标节点数>

2. 调整cert-manager资源配置 #

查看当前cert-manager Deployment的资源限制，确认是否内存配额过低：

kubectl get deployment cert-manager -n cert-manager -o yaml | grep -A 6 -B 2 resources

若未配置内存限制或值过小，更新Deployment的资源配置（示例配置）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cert-manager
  namespace: cert-manager
spec:
  template:
    spec:
      containers:
      - name: cert-manager
        resources:
          requests:
            memory: "256Mi"
            cpu: "100m"
          limits:
            memory: "512Mi"
            cpu: "500m"

应用更新：

kubectl apply -f <更新后的yaml文件> -n cert-manager

3. 清理异常Pod #

直接删除状态异常的Pod，让控制器重新创建实例：

kubectl delete pod <异常Pod名称> -n cert-manager

4. 检查节点异常事件 #

查看节点的事件记录，确认是否有OOM Killer触发或节点重启的情况：

kubectl describe node <节点名称>

重点关注Events区域，寻找OOM killing process、NodeNotReady等相关日志，定位节点层面的问题。

5. 验证正常Pod日志 #

若重新创建的Pod恢复运行，查看日志确认是否存在内存相关报错：

kubectl logs <正常运行的cert-manager Pod> -n cert-manager

若日志中出现内存不足相关信息，进一步确认是Pod配额还是节点资源的问题，针对性调整。

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