K8S系统Pod部署在Worker节点而非Master节点问题咨询

这正是K8s污点（Taint）与容忍（Toleration）机制设计的典型场景之一——通过节点污点限制Pod调度范围，配合Pod的容忍度让核心系统组件仅能部署在Master节点，避免Worker节点故障影响集群核心功能。

具体操作步骤如下：

1. 为Master节点添加/恢复默认污点
   Master节点默认带有node-role.kubernetes.io/control-plane:NoSchedule污点（部分旧版本为node-role.kubernetes.io/master），这个污点会阻止普通业务Pod调度到Master，但核心系统组件（如kube-apiserver、kube-controller-manager）默认自带对应容忍度，能正常部署。如果你的Master节点没有这个污点，执行以下命令添加：

   kubectl taint nodes <master-node-name> node-role.kubernetes.io/control-plane:NoSchedule
   

2. 为Worker节点添加污点
   给所有Worker节点添加专属污点，阻止无对应容忍度的Pod（包括系统组件、Metrics Server）调度过来：

   kubectl taint nodes <worker-node-name> node-role.kubernetes.io/worker:NoSchedule
   

3. 确保系统Pod和Metrics Server带有Master节点污点的容忍度
   大部分K8s核心系统组件默认已经配置了对Master节点污点的容忍，但Metrics Server可能需要手动修改其Deployment配置。编辑Metrics Server的Deployment：

   kubectl edit deployment metrics-server -n kube-system
   

   在Pod模板的tolerations字段中添加如下配置：

   tolerations:
   - key: "node-role.kubernetes.io/control-plane"
     operator: "Exists"
     effect: "NoSchedule"
   

4. （可选）配合节点亲和性强化调度规则
   为了更保险，可以给系统Pod和Metrics Server添加节点亲和性，强制它们只能调度到带有Master角色标签的节点：
   在Pod模板的affinity字段中添加：

   affinity:
     nodeAffinity:
       requiredDuringSchedulingIgnoredDuringExecution:
         nodeSelectorTerms:
         - matchExpressions:
           - key: node-role.kubernetes.io/control-plane
             operator: Exists
   

完成以上操作后，所有系统Pod和Metrics Server会被限制在Master节点运行，Worker节点仅用于部署业务Pod，即使Worker节点宕机，集群核心组件仍能正常工作。

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