1 个节点存在 Pod 在 Kubernetes 集群中无法容忍的污点

Question

今天我的 kubernetes 集群 v1.15.2 给了我这个错误：1 node(s) had taints that the pod didn't toleratepods 无法启动。

它告诉我一个节点有污点，我检查节点状态并且工作正常，如何知道它到底有污点？

我正在从互联网上搜索，所有人都告诉我主节点无法为默认运行的 pod 分配。但是现在我的 kubernetes pod 没有运行主节点。

• 什么可能导致我的节点有污点（例如这个节点没有足够的资源）？
• 我应该怎么做才能找出节点的污点并修复它？

Answer 1

默认情况下，主节点受到污染（意味着不会在主节点上调度 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 前面添加

Answer 2

您可以使用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您toleration在 pod 规范中没有对应的节点，则通常会出现错误。

下面是一个具有容忍度的示例 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"