kubernetes中master节点默认带node-role.kubernetes.io/master:noschedule污点，阻止业务pod调度；可通过移除污点（仅限测试环境）、为pod添加对应tolerations（推荐），或配合uncordon解除调度封锁来解决。
在Kubernetes集群中，使用kubeadm部署的默认配置会让Master节点带有污点（taint），导致业务Pod无法被调度到该节点上运行；若需让Master节点同时承担工作负载，必须显式解除其排斥行为或让Pod主动声明容忍。
确认Master节点当前是否被标记为不可调度
执行命令查看节点状态和污点信息：
```kubectl get nodes -o wide```
若输出中Master节点的STATUS列含NotReady或ROLES列为master且无SchedulingDisabled提示，仍需进一步检查污点。
运行：
```kubectl describe node $(hostname) | grep Taints```
若返回类似 Taints: node-role.kubernetes.io/master:NoSchedule，说明污点存在——这是阻止Pod调度的根本原因。
方法一：移除Master节点上的污点（适用于测试/单节点环境）
执行命令清除默认污点：
```kubectl taint node $(hostname) node-role.kubernetes.io/master:NoSchedule-```
注意：该操作会直接解除对所有Pod的调度限制，【生产环境严禁执行】。因为Master组件（如etcd、kube-apiserver）与业务容器共享资源，可能引发稳定性风险或OOM Kill。
验证是否生效：
```kubectl get nodes -o wide``` → 查看SCHEDULABLE列是否变为True；再创建一个测试Pod，观察其NODE字段是否可能出现Master主机名。
方法二：为Pod添加tolerations容忍污点（推荐方式）
无需改动节点配置，仅修改Pod或控制器（Deployment/StatefulSet等）的YAML定义，在spec下插入tolerations字段：
方法一（兼容老版本k8s）：
```yaml
tolerations:
- key: "node-role.kubernetes.io/master"
operator: "Exists"
effect: "NoSchedule"
```
方法二（更精确匹配，推荐）：
```yaml
tolerations:
- key: "node-role.kubernetes.io/control-plane"
operator: "Exists"
effect: "NoSchedule"
```
从v1.25起，kubeadm默认使用control-plane替代master作为污点key，务必用kubectl describe node确认实际key名后再填写。
保存后应用配置：
```kubectl apply -f my-app.yaml```
此时Pod将能被调度到Master节点，前提是该节点资源余量充足且未被其他策略（如nodeSelector、affinity）排除。
方法三：启用Master节点的可调度状态（uncordon）
第一步：检查节点是否处于cordon状态：
```kubectl get nodes``` → 若Master节点的STATUS列显示SchedulingDisabled，说明已被手动封锁。
第二步：解除封锁：
```kubectl uncordon $(hostname)```
这一步只是放开“可调度”开关，但不解决污点问题；它必须与方法一或方法二配合使用才有效。单独执行uncordon后，带污点的Master仍不会接收新Pod。
