1个节点有豆荚在kubernetes集群中不容忍的污点 [英] 1 node(s) had taints that the pod didn't tolerate in kubernetes cluster

问题描述

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

Today my kubernetes cluster v1.15.2 give me this error: 1 node(s) had taints that the pod didn't tolerate and the pods could not start.

它告诉我一个节点有污点，我检查节点状态是否正常，如何知道它到底有污点?

It tells me one nodes have taints and I check the node status and works fine, how to know it exactly have taints?

我正在从Internet进行搜索，所有信息都告诉我，默认情况下，主节点无法分配给运行的Pod.但是现在我的kubernetes pods没有运行主节点.

I am searching from intenet and all tells me that master node could not allocate for pods running by default. But now my kubernetes pods is not running a master node.

• 什么可能导致我的节点有污点(例如，该节点没有足够的资源)?
• 我应该怎么做才能找出节点的污点并进行修复?

推荐答案

您可以使用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

当某些条件为真时，节点控制器会自动污染节点.内置以下污点:

The node controller automatically taints a Node when certain conditions are true. The following taints are built in:

node.kubernetes.io/not-ready:节点未准备好.这对应于NodeCondition Ready为"False".

node.kubernetes.io/not-ready: Node is not ready. This corresponds to the NodeCondition Ready being "False".

node.kubernetes.io/unreachable:无法从节点控制器访问节点.这对应于准备好NodeCondition"为未知".

node.kubernetes.io/unreachable: Node is unreachable from the node controller. This corresponds to the NodeCondition Ready being "Unknown".

node.kubernetes.io/out-of-disk:节点磁盘空间不足.

node.kubernetes.io/out-of-disk: Node becomes out of disk.

node.kubernetes.io/memory-pressure:节点内存不足.

node.kubernetes.io/disk-pressure:节点具有磁盘压力.

node.kubernetes.io/disk-pressure: Node has disk pressure.

node.kubernetes.io/network-unavailable:节点的网络不可用.

node.kubernetes.io/network-unavailable: Node's network is unavailable.

node.kubernetes.io/unschedulable:节点不可调度.

node.cloudprovider.kubernetes.io/uninitialized:当kubelet以"external"开始时，云提供商，此污点设置在节点上以将其标记为不可用.来自cloud-controller-manager的控制器初始化此节点后，kubelet会删除此污点.

node.cloudprovider.kubernetes.io/uninitialized: When the kubelet is started with "external" cloud provider, this taint is set on a node to mark it as unusable. After a controller from the cloud-controller-manager initializes this node, the kubelet removes this taint.

上面带有特殊异味node-role.kubernetes.io/master:NoSchedule的区域默认情况下被添加到主节点.

Along with above a special taint node-role.kubernetes.io/master:NoSchedule is added by default to master nodes.

如果在节点中没有对应的toleration的节点上有taint，通常会出现错误.

The error typically comes if there is a taint on nodes for which you don't have corresponding toleration in pod spec.

下面是带有容忍度的示例豆荚.

Below is an example pod with toleration.

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"

这篇关于1个节点有豆荚在kubernetes集群中不容忍的污点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！