Azure Kubernetes：OOMKilled(退出码137)且自动扩容未触发问题排查

一、核心原因分析 #

1. 容器资源配置不匹配 #

• 容器的memory limit设置远低于应用实际内存需求，导致单个容器先触发OOM，此时节点仍有剩余可调度资源（基于Pod的memory request计算），集群自动扩容不会被触发。因为AKS自动扩容的触发逻辑是节点无法满足新Pod的request资源需求，而非单个容器的实际使用超过limit。
• 若Pod未设置memory request，AKS会默认使用limit值作为request，此时如果节点总资源能容纳request，但容器实际用超limit，同样只会触发容器OOM，不会扩容。

2. 集群自动扩容（Cluster Autoscaler）配置或运行异常 #

• 触发阈值未达标：AKS Cluster Autoscaler默认需要等待一定时间（默认10分钟）确认资源持续不足才会扩容，若OOM是瞬时发生或未达到持续时间要求，不会触发扩容。另外，若节点的可分配资源（CPU/memory）仍能满足Pod的request，CA不会启动扩容。
• 调度约束限制：Pod配置了nodeSelector、affinity或toleration，但扩容的节点池不满足这些约束（比如节点池的标签不匹配、没有对应污点容忍），导致CA无法找到合适的节点池进行扩容。
• Cluster Autoscaler未正常运行：CA的Pod处于CrashLoopBackOff或未就绪状态，无法正常检测资源需求和发起扩容请求；或者AKS集群的服务主体权限不足，无法调用Azure资源管理器创建新节点。

3. 节点资源被挤占 #

节点上的其他Pod已占用大量资源，导致当前Pod调度到节点后，实际可用内存不足，但Pod的request设置较低，CA认为节点仍有足够资源容纳request，因此不触发扩容，而容器实际运行时超过节点剩余内存，触发OOM。

二、解决步骤 #

1. 调整容器资源配置 #

• 先通过kubectl describe pod <pod-name>查看Pod的资源request/limit设置，再用kubectl top pod <pod-name>查看容器实际内存使用情况。
• 根据实际使用量，合理设置memory request和memory limit：request应接近容器常规运行的内存需求，limit设置为峰值内存的1.2-1.5倍，避免容器频繁OOM，同时让CA能准确判断节点资源是否充足。
• 示例配置：

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

2. 检查并修复Cluster Autoscaler配置 #

• 验证CA运行状态：执行kubectl get pods -n kube-system | grep cluster-autoscaler，确保Pod处于Running状态。若异常，查看日志：kubectl logs <ca-pod-name> -n kube-system，排查权限或配置问题。
• 调整扩容阈值：若需要更灵敏的扩容，可修改CA的启动参数，比如--scale-up-delay=3m缩短等待时间（注意避免频繁扩容缩容）。在AKS中可通过Azure CLI更新：

  az aks update -g <resource-group> -n <cluster-name> --cluster-autoscaler-profile scale-up-delay=3m
  

• 检查调度约束：确认Pod的nodeSelector/affinity与节点池的标签匹配，若使用污点容忍，确保节点池的污点和Pod的toleration一致。比如节点池标签为node-type: app，Pod的nodeSelector需设置对应标签。

3. 排查节点资源使用情况 #

• 执行kubectl top node查看节点的CPU/memory使用率，确认节点是否真的资源不足。
• 若节点已接近资源上限，检查节点上的其他Pod是否有资源浪费，比如闲置Pod可清理；或调整Pod的request，让CA能正确识别节点资源不足，触发扩容。

4. 验证AKS服务主体权限 #

确保AKS集群的服务主体拥有Microsoft.Compute/virtualMachineScaleSets/write权限，可通过Azure Portal或CLI检查服务主体的角色分配，若缺失则添加对应权限。

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