您可以使用kubectl describe node <nodename>来检查污点。

kubectl describe node masternode
Name:               masternode
Roles:              master
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=ip-10-0-0-115
                    kubernetes.io/os=linux
                    node-role.kubernetes.io/master=
Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                    node.alpha.kubernetes.io/ttl: 0
                    projectcalico.org/IPv4Address: 10.0.0.115/24
                    projectcalico.org/IPv4IPIPTunnelAddr: 192.168.217.0
                    volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp:  Thu, 18 Jun 2020 10:21:48 +0530
Taints:             node-role.kubernetes.io/master:NoSchedule

当某些条件为真时，节点控制器会自动污染节点。以下污染是内置的：
node.kubernetes.io/not-ready：节点未就绪。这对应于NodeCondition Ready为“False”。
node.kubernetes.io/unreachable：无法从节点控制器访问节点。这对应于NodeCondition Ready为“未知”。
node.kubernetes.io/out-of-disk：节点超出磁盘空间。
node.kubernetes.io/memory-pressure：节点存在内存压力。
node.kubernetes.io/disk-pressure：节点具有磁盘压力。
node.kubernetes.io/network-unavailable：节点的网络不可用。
node.kubernetes.io/unschedulable：节点不可计划。
node.cloudprovider.kubernetes.io/uninitialized：当kubelet使用“外部”云提供程序启动时，此污点将在节点上设置，以将其标记为不可用。来自cloud-controller-manager的控制器初始化此节点后，kubelet将删除此污点。
除上述之外，默认情况下还会向主节点添加一个特殊的污点node-role.kubernetes.io/master:NoSchedule。
如果节点上存在taint，而pod规范中没有对应的toleration，则通常会出现此错误。
以下是一个带有公差的pod示例。

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "example-key"
    operator: "Exists"
    effect: "NoSchedule"

默认情况下，主节点已感染（意味着不会在主节点上安排任何pod或工作负载。这是最佳做法，因为主节点要运行ETCD等群集组件，kubeapi-server等和所有其它应用相关的POD应该进入工作节点），所以这就是为什么默认情况下污点应用在主节点上。污点和容限一起工作以确保POD不被调度到不适当的节点上。将一个或多个污点应用于节点。
检查节点是否已损坏

kubectl describe node <nodename> | grep Taints

如果节点上存在任何污点，您将得到如下所示的结果

node-role.kubernetes.io/master:NoSchedule

如果您希望保持节点上的污点不变，并且仍然希望在该节点上调度特定pod，则将其包含在pod/deployment.yaml文件中。

tolerations:
- key: "key"
  operator: "Exists"
  effect: "NoSchedule"

要获取更多信息，请查看此部分https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
如果您想从该节点中删除污点，请执行以下步骤
首先检查节点名是否存在污点

kubectl describe node <nodename> | grep Taints

您将得到如下所示的内容（master或worker_node）

node-role.kubernetes.io/master:NoSchedule

要从节点中删除污点，只需像这样运行（在我的情况下，它是主节点）

kubectl taint node master node-role.kubernetes.io/master:NoSchedule-

确保在NoSchedule前面添加-

kubectl describe node nodename | grep Taints

kubectl taint node master node-role.kubernetes.io/master:NoSchedule-

这个很好用

这将为您列出所有内容：

kubectl获取节点-o json| jq '.项目[].质量标准污染'

[
  {
    "effect": "NoSchedule",
    "key": "node.kubernetes.io/unschedulable",
    "timeAdded": "2022-03-29T15:13:37Z"
  }
]
null
null
[
  {
    "effect": "NoSchedule",
    "key": "node.kubernetes.io/unschedulable",
    "timeAdded": "2022-03-29T15:13:37Z"
  }
]

• 试试这个 *

kubectl describe node <nodename> | grep Taints

• 你会得到这样的东西 *

node-role.kubernetes.io/master:NoSchedule

• 去除污点 *

kubectl taint node <master-nodename> node-role.kubernetes.io/master:NoSchedule-