Azure AKS系统与用户节点池配置后Pod调度异常问询

我在Azure AKS实例上配置了系统与用户节点池，此前仅使用系统节点池承载应用与系统Pod。具体操作：

• 创建带CriticalAddonsOnly=true:NoSchedule污点的系统节点池，避免应用微服务调度至此；
• 将原有系统节点池转为用户节点池；
• 重启gatekeeper-system、kube-system下的多个部署，使系统Pod调度至新系统节点池。

但目前系统Pod虽已调度到新系统节点池，却仍在所有用户节点池存在，手动删除后会立即重建。请问此行为是否正常？按逻辑系统Pod是否应仅存在于系统节点池？

1. 此行为不正常，正常逻辑下，系统Pod应仅调度到系统节点池，不会在用户节点池持续存在并自动重建。

2. 核心排查点：

   • 节点池标签/污点配置：确认原系统池转为用户池后，是否已移除kubernetes.azure.com/mode: system标签，同时新系统池是否正确保留该标签。如果原池仍带有系统池标识，调度器会误将其视为系统池，继续调度系统Pod。
   • 系统Pod的调度约束：检查kube-system、gatekeeper-system下的Deployment资源，查看是否配置了nodeSelector或affinity规则，限制Pod仅调度到系统节点池。若缺少这类约束，调度器会把系统Pod调度到任何满足资源条件的节点（包括用户池）。
   • DaemonSet类型组件区分：部分系统组件（如kube-proxy、azure-cni-node）是以DaemonSet形式部署的，这类Pod默认会在每个节点上运行实例，在用户节点池存在是正常行为。但如果是Deployment类型的系统Pod（如coredns、gatekeeper），则不应出现在用户节点池。
   • 容忍度匹配情况：确认新系统池的CriticalAddonsOnly=true:NoSchedule污点，是否被系统Pod的容忍度正确匹配。若部分Pod缺少对应容忍度，可能无法调度到新系统池，但这不是用户池持续重建Pod的直接原因。

3. 修复步骤：

   • 为所有系统Deployment添加nodeSelector配置，指定仅选择带有kubernetes.azure.com/mode: system标签的节点：

     spec:
       template:
         spec:
           nodeSelector:
             kubernetes.azure.com/mode: system
     

   • 验证原系统池转为用户池后的标签状态，确保已移除系统池相关标识；
   • 对于需要限制在系统池运行的DaemonSet组件，添加相同的nodeSelector规则，避免其在用户节点池部署。

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