AKS节点超出最大卷数限制时自动伸缩未触发扩容问题排查

Pod持续Pending、自动伸缩不触发是规则配置错误+节点资源配额耗尽两个问题共同导致的：

1. Pod亲和性与反亲和性规则逻辑互斥，直接阻断扩容逻辑 #

你配置的强制调度规则存在不可调和的冲突：

• podAffinity规则要求：待调度Pod必须和带有bp-app: app标签的Pod调度到同一节点（拓扑域为节点hostname）
• 第一条podAntiAffinity规则同时要求：待调度Pod不能和带有bp-app: app标签的Pod调度到同一节点（拓扑域同样为节点hostname）

这两个规则完全矛盾：

• 现有节点上已经运行了带bp-app: app标签的Pod，会触发反亲和性排斥，无法调度新Pod
• 自动伸缩器模拟扩容出的全新节点上没有任何同标签Pod，无法满足亲和性的共置要求
  无论集群扩多少节点，都不可能满足这组互斥规则，因此自动伸缩器直接返回NotTriggerScaleUp，不会执行任何扩容动作。

2. 现有节点已达到Azure数据盘挂载上限 #

你使用的Standard_D16s_v3规格节点，Azure平台单节点最多支持挂载32块数据盘，对应Kubernetes集群中Azure Disk类型PVC的单节点挂载上限。从事件日志看，当前3个节点都已经超出最大卷数量阈值，即使不存在亲和性规则冲突，现有节点也无法调度需要挂载新数据盘PVC的Pod。

• 第一步修正互斥的调度规则：如果你的需求是同应用Pod跨节点、跨可用区打散部署，直接删除同hostname维度的强制Pod亲和性规则即可，仅保留两条反亲和性规则就能满足打散要求，不存在调度逻辑冲突。
• 规则修正后，自动伸缩器会重新模拟调度，识别到新增节点可以满足Pod调度要求，就会自动触发节点池扩容，直到Pod成功调度或达到节点池最大节点数上限。
• 如果后续节点池扩容到最大6个节点仍出现卷数量不足的报错，可以更换单节点数据盘挂载配额更高的节点规格，或者将低IO要求的工作负载PVC迁移到Azure File存储类（不占用节点数据盘挂载配额），缓解配额压力。

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