k8s--pod 调度、定向调度、亲和性调度、污点和容忍
介绍
在默认情况下，一个 pod 在哪个 node 节点上运行，是由 Scheduler 组件采用相应的算法算出来的，这个过程是不受人工控制的。但是在实际使用中，这并不满足需求，因为在很多情况下，我们想控制某些 pod 到达某些节点上，那么应该怎么做呢？这就涉及到 kubernetes 对 pod 的调度规则，kubernetes 提供了四大类调度方式
- 自动调度：运行在哪个节点上完全由 Scheduler 经过一系列的算法计算得出
- 定向调度：有两种，根据节点名称（NodeName）或者节点选择器（NodeSelector）
- 亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity
- 污点（容忍）调度：Taints、Toleration
默认就是自动调度，所以下面来看其他的几种调度方式
定向调度
定向调度，指的是利用在 pod 上声明 nodeName 或者 nodeSelector，以此将 pod 调度到期望的 node 节点上。注意，这里的调度是强制的，这就意味着即使要调度的目标 node 不存在，也会向上面进行调度，只不过 pod 运行失败而已
NodeName
NodeName 用于强制将 pod 调度到指定的 name 的 node 节点上，这种方式，其实是直接跳过 Scheduler 的调度逻辑，直接将 pod 调度到指定名称的节点
接下来，实验一下：创建一个 pod-nodename.yaml 文件
apiVersion: v1 kind: Pod metadata: name: pod-nodename namespace: zouzou spec: containers: - name: nginx image: nginx:1.14 nodeName: dce-10-6-215-190 # 指定调度到 dce-10-6-215-190 节点上
如果你不知道 nodeName 的话，使用下面命令查看
kubectl get node
创建 pod，查看 pod
# 创建 pod kubectl apply -f pod-nodename.yaml
查看 pod 的信息，可以看到 pod 已经分配给了 dce-10-6-215-190 的节点上
# 可以看到 pod 分配到了 dce-10-6-215-190 的节点上，有人说，可能是随机分配的，那你也可以写一个不存在的 node 地址试下 [root@dce-10-6-215-215 tmp]# kubectl get pod pod-nodename -n zouzou -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-nodename 1/1 Running 0 89s 172.29.190.141 dce-10-6-215-190 <none> <none>
NodeSelector
NodeSelector 用于将 pod 调度到添加了指定标签的 node 节点上，它是通过 kubernetes 的 label-selector 机制实现的，也就是说，在 pod 创建之前，会由 scheduler 使用 MatchNodeSelector 调度策略进行 label 匹配，找出目标 node，然后将 pod 调度到目标节点，该匹配规则是强制约束。
接下来，实验一下：首先查看下节点的 labels
[root@dce-10-6-215-215 tmp]# kubectl get node --show-labels NAME STATUS ROLES AGE VERSION LABELS dce-10-6-215-190 Ready <none> 7d3h v1.18.20 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=dce-10-6-215-190,kubernetes.io/os=linux dce-10-6-215-200 Ready <none> 7d1h v1.18.20 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=dce-10-6-215-200,kubernetes.io/os=linux dce-10-6-215-215 Ready master,registry 8d v1.18.20 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=dce-10-6-215-215,kubernetes.io/os=linux,node-role.kubernetes.io/master=,node-role.kubernetes.io/registry=
上面有很多的标签，为了测试方便，在此基础上给两个 node 节点添加两个简单的标签
kubectl label node dce-10-6-215-190 nodeenv=pro
kubectl label node dce-10-6-215-200 nodeenv=test
在来查看下对应的标签
这样我们就给两个节点打上了标签
创建一个 pod-nodeselector.yaml 文件，并使用它创建 Pod
apiVersion: v1 kind: Pod metadata: name: pod-nodeselector namespace: zouzou spec: containers: - name: nginx image: nginx:1.14 nodeSelector: nodeenv: pro # 指定调度到具有 nodeenv=pro 标签的节点上
创建 pod 查看详情，可以看到，pod 分配给了 nodeenv=pro 的标签节点上
# 创建 pod [root@dce-10-6-215-215 tmp]# kubectl apply -f pod-nodeselector.yaml pod/pod-nodeselector created # 查看 pod 在 dce-10-6-215-190 上了，你也可以写个不存在的标签测试是不是随机分配的 [root@dce-10-6-215-215 tmp]# kubectl get pod pod-nodeselector -n zouzou -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-nodeselector 1/1 Running 0 48s 172.29.190.142 dce-10-6-215-190 <none> <none>
亲和性调度
上面，介绍了两种定向调度的方式，使用起来非常方便，但是也有一定的问题，那就是如果没有满足条件的 node，那么 pod 将不会被运行，即使在集群中还有可用 node 列表也不行，这就限制了它的使用场景
基于上面的问题，kubernetes 还提供了一种亲和度（Affinity）调度。它在 NodeSelector 的基础上进行了扩展，可以通过配置的形式，实现优先选择满足条件的 Node 进行调度，如果没有，也可以调度到不满足条件的节点上，使调度更加灵活
Affinity 主要分为三类
- nodeAffinity（node 亲和性）：以 node 为目标，解决 pod 可以调度到哪些 node 上的问题
- podAffinity（pod 亲和性）：以 pod 为目标，解决 pod 可以和哪些已存在的 pod 部署在同一个拓扑域中的问题
- podAntiAffinity（pod 反亲和性）：以 pod 为目标，解决 pod 不能和哪些已存在 pod 部署在同一个拓扑域中的问题
关于亲和性和反亲和性使用场景的说明：
亲和性：如果两个应用频繁交互，那就有必要利用亲和性让两个应用尽可能的靠近，这样可以减少因网络通信而带来的性能损耗，比如 web 应用和 mysql，要频繁的从数据库里查询和新增数据，所以应该让他们尽可能的在一起
反亲和性：当应用采用多副本部署时，有必要采用反亲和性让各个应用实例打散分布在各个 node 上，这样可以提高服务的高可用性，当一个服务器挂掉之后，其他的 pod 还可以提供服务
NodeAffinity
首先来看一下 NodeAffinity 的可配置项：
pod.spec.affinity.nodeAffinity requiredDuringSchedulingIgnoredDuringExecution # Node节点必须满足指定的所有规则才可以，相当于硬限制 nodeSelectorTerms # 节点选择列表 matchFields # 按节点字段列出的节点选择器要求列表 matchExpressions # 按节点标签列出的节点选择器要求列表(推荐) key # 键 values # 值 operat or # 关系符 支持Exists, DoesNotExist, In, NotIn, Gt, Lt preferredDuringSchedulingIgnoredDuringExecution # 优先调度到满足指定的规则的 Node，相当于软限制 (倾向) preference # 一个节点选择器项，与相应的权重相关联 matchFields # 按节点字段列出的节点选择器要求列表 matchExpressions # 按节点标签列出的节点选择器要求列表(推荐) key # 键 values # 值 operator # 关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Lt weight # 倾向权重，在范围1-100。
关系符的说明
- matchExpressions: - key: nodeenv # 匹配存在标签的 key 为 nodeenv 的节点 operator: Exists - key: nodeenv # 匹配标签的 key 为 nodeenv,且 value 是 "xxx" 或 "yyy" 的节点 operator: In values: ["xxx","yyy"] - key: nodeenv # 匹配标签的 key 为 nodeenv,且 value 大于 "xxx" 的节点 operator: Gt values: "xxx"
接下来首先演示一下 requiredDuringSchedulingIgnoredDuringExecution
创建 pod-nodeaffinity-required.yaml，内容如下
apiVersion: v1 kind: Pod metadata: name: pod-nodeaffinity-required namespace: zouzou spec: containers: - name: nginx image: nginx:1.14 affinity: # 亲和性设置 nodeAffinity: # 设置 node 亲和性 requiredDuringSchedulingIgnoredDuringExecution: # 硬限制，没有满足就会失败 nodeSelectorTerms: # node 选择器，可以有多个 - matchExpressions: # 匹配标签 - key: nodeenv # 标签的 key 要为 nodeenv operator: In # 操作符，在里面 values: ["xxx","yyy"] # 值在["xxx","yyy"]中的标签
创建 pod
# 创建 pod kubectl create -f pod-nodeaffinity-required.yaml
查看 pod 和 pod 的 event
# 查看 pod ，发现 pod 没有调度到节点上，因为 nodeenv 的值没有 xxx 或者 yyy，而且是硬限制 [root@dce-10-6-215-215 tmp]# kubectl get pod pod-nodeaffinity-required -n zouzou -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-nodeaffinity-required 0/1 Pending 0 81s <none> <none> <none> <none> # 从 event 可以看到，调度失败，有三个 node 节点，但是没有满足标签选择器的 node [root@dce-10-6-215-215 tmp]# kubectl describe pod pod-nodeaffinity-required -n zouzou Name: pod-nodeaffinity-required Namespace: zouzou Priority: 0 Node: <none> Labels: <none> ...... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 104s default-scheduler 0/3 nodes are available: 3 node(s) didn't match node selector. Warning FailedScheduling 30s default-scheduler 0/3 nodes are available: 3 node(s) didn't match node selector.
从上面我们可以看出，硬限制当没有匹配的标签时，会调度失败。因为我们两个 node 节点，只有 nodeenv=pro 和 nodeenv=test 的节点，没有 nodeenv=xxx 或者 nodeenv=yyy 的节点
接下来，我们删除 pod，把 yyy 改为 pro，因为 nodeenv=pro 是存在的
# 删除 pod kubectl delete -f pod-nodeaffinity-required.yaml
修改后在创建 pod
# 创建 pod kubectl create -f pod-nodeaffinity-required.yaml
查看 pod
# 可以看到，pod 分配给了 dce-10-6-215-190 的节点上，并成功运行了
[root@dce-10-6-215-215 tmp]# kubectl get pod pod-nodeaffinity-required -n zouzou -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-nodeaffinity-required 1/1 Running 0 17s 172.29.190.143 dce-10-6-215-190 <none> <none> # 从 event 里，也可以看出来，是成功调度的 [root@dce-10-6-215-215 tmp]# kubectl describe pod pod-nodeaffinity-required -n zouzou Name: pod-nodeaffinity-required Namespace: zouzou...... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 24s default-scheduler Successfully assigned zouzou/pod-nodeaffinity-required to dce-10-6-215-190 Normal Pulled 21s kubelet Container image "nginx:1.14" already present on machine Normal Created 21s kubelet Created container nginx Normal Started 20s kubelet Started container nginx
接下来再演示一下 requiredDuringSchedulingIgnoredDuringExecution
创建 pod-nodeaffinity-preferred.yaml，内容如下
apiVersion: v1 kind: Pod metadata: name: pod-nodeaffinity-preferred namespace: zouzou spec: containers: - name: nginx image: nginx:1.14 affinity: # 亲和性设置 nodeAffinity: # 设置 node 亲和性 preferredDuringSchedulingIgnoredDuringExecution: # 软限制，没有匹配的标签也会分配给某个 node - weight: 1 # 权重 preference: # 一个节点选择器项，与相应的权重相关联 matchExpressions: # 匹配标签 - key: nodeenv # 标签的 key 要为 nodeenv operator: In # 操作符，在里面 values: ["xxx","yyy"] # 匹配 env 的值在["xxx","yyy"]中的标签(当前环境没有)
创建 pod
kubectl create -f pod-nodeaffinity-preferred.yaml
查看 pod 和 pod event
# 可以看到，成功分配给了 dce-10-6-215-200 的节点上 [root@dce-10-6-215-215 tmp]# kubectl get pod pod-nodeaffinity-preferred -n zouzou -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-nodeaffinity-preferred 1/1 Running 0 53s 172.29.34.238 dce-10-6-215-200 <none> <none> # 从 event 中也可以看出，pod 是调度成功的 [root@dce-10-6-215-215 tmp]# kubectl describe pod pod-nodeaffinity-preferred -n zouzou Name: pod-nodeaffinity-preferred Namespace: zouzou Priority: 0 Node: dce-10-6-215-200/10.6.215.200 Start Time: Sat, 16 Apr 2022 11:45:15 +0800 ...... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 66s default-scheduler Successfully assigned zouzou/pod-nodeaffinity-preferred to dce-10-6-215-200 Normal Pulled 63s kubelet Container image "nginx:1.14" already present on machine Normal Created 63s kubelet Created container nginx Normal Started 62s kubelet Started container ngin
从上面的结果可以看出，软限制，当没有匹配到对应的标签时，也不会调度失败，会根据算法分配给合适的节点
NodeAffinity规则设置的注意事项：
- 如果同时定义了 nodeSelector 和 nodeAffinity，那么必须两个条件都得到满足，Pod 才能运行在指定的 Node 上
- 如果 nodeAffinity 指定了多个 nodeSelectorTerms，那么只需要其中一个能够匹配成功即可
- 如果一个 nodeSelectorTerms 中有多个 matchExpressions ，则一个节点必须满足所有的才能匹配成功
- 如果一个 pod 所在的 Node 在 Pod 运行期间其标签发生了改变，不再符合该 Pod 的节点亲和性需求，则系统将忽略此变化
PodAffinity
PodAffinity 主要实现以运行的 Pod 为参照，实现让新创建的 Pod 跟参照 pod 在一个区域的功能。
首先来看一下 PodAffinity 的可配置项：
pod.spec.affinity.podAffinity requiredDuringSchedulingIgnoredDuringExecution # 硬限制 namespaces # 指定参照 pod 的 namespace topologyKey # 指定调度作用域 labelSelector # 标签选择器 matchExpressions # 按节点标签列出的节点选择器要求列表(推荐) key # 键 values # 值 operator # 关系符 支持 In, NotIn, Exists, DoesNotExist. matchLabels # 指多个 matchExpressions 映射的内容 preferredDuringSchedulingIgnoredDuringExecution # 软限制 podAffinityTerm # 选项 namespaces topologyKey labelSelector matchExpressions key # 键 values # 值 operator matchLabels weight # 倾向权重，在范围 1-100
topologyKey 用于指定调度时作用域
- 如果指定为 kubernetes.io/hostname，那就是以 Node 节点为区分范围
- 如果指定为 beta.kubernetes.io/os，则以 Node 节点的操作系统类型来区分
接下来，演示下 requiredDuringSchedulingIgnoredDuringExecution（硬限制）
首先创建一个参照 Pod，pod-podaffinity-target.yaml，内容如下
apiVersion: v1 kind: Pod metadata: name: pod-podaffinity-target namespace: zouzou labels: podenv: pro # 给 pod 设置标签 spec: containers: - name: nginx image: nginx:1.14 nodeName: dce-10-6-215-200 # 将目标 pod 明确指定到 dce-10-6-215-200 上
创建 pod
kubectl apply -f pod-podaffinity-target.yaml
接下来创建 创建 pod-podaffinity-required.yaml，内容如下：
apiVersion: v1 kind: Pod metadata: name: pod-podaffinity-required namespace: zouzou spec: containers: - name: nginx image: nginx:1.14 affinity: # 亲和性设置 podAffinity: # 设置pod亲和性 requiredDuringSchedulingIgnoredDuringExecution: # 硬限制 - labelSelector: matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签 - key: podenv # 对应的是 pod 的标签，不是 node 的，上面创建参照 pod 的时候创建了一个 podenv=pro 的标签 operator: In values: ["xxx","yyy"] # 不存在 podenv=xxx 或者 podenv=yyy topologyKey: kubernetes.io/hostname # 以 node 节点为区分范围
上面配置表达的意思是：新 Pod 必须要与拥有标签 podenv=xxx 或者 podenv=yyy 的 pod 在同一 Node 上，显然现在没有这样 pod，接下来，运行测试一下
# 创建 pod kubectl create -f pod-podaffinity-required.yaml
查看 pod 和 pod event
# 查看 pod，发现 pod 未运行，也没有分配到节点上 [root@dce-10-6-215-215 tmp]# kubectl get pods pod-podaffinity-required -n zouzou -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-podaffinity-required 0/1 Pending 0 30s <none> <none> <none> <none> # 查看 event，底下提示有三个节点，一个节点有污点（master），两个节点（node）不满足标签规则 [root@dce-10-6-215-215 tmp]# [root@dce-10-6-215-215 tmp]# kubectl describe pod pod-nodeaffinity-preferred -n zouzou Name: pod-nodeaffinity-preferred Namespace: zouzou Priority: 0 Node: dce-10-6-215-200/10.6.215.200 Start Time: Sat, 16 Apr 2022 11:45:15 +0800 ...... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 51s default-scheduler 0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 node(s) didn't match pod affinity rules, 2 node(s) didn't match pod affinity/anti-affinity.
接下来修改 values: ["xxx","yyy"]----->values:["pro","yyy"]
意思是：新 Pod 必须要与拥有标签 podenv=xxx 或者 podenv=yyy 的 pod 在同一 Node 上
修改完之后重新创建 pod
# 创建 pod kubectl create -f pod-podaffinity-required.yaml
查看 pod，是正常运行的
# 查看 pod，pod 是正常运行的 [root@dce-10-6-215-215 tmp]# kubectl get pods pod-podaffinity-required -n zouzou -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-podaffinity-required 1/1 Running 0 36s 172.29.34.240 dce-10-6-215-200 <none> <none> # 查看 event，正常 [root@dce-10-6-215-215 tmp]# kubectl describe pods pod-podaffinity-required -n zouzou Name: pod-podaffinity-required Namespace: zouzou Priority: 0 Node: dce-10-6-215-200/10.6.215.200 Start Time: Sat, 16 Apr 2022 12:19:04 +0800 ...... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 41s default-scheduler Successfully assigned zouzou/pod-podaffinity-required to dce-10-6-215-200 Normal Pulled 39s kubelet Container image "nginx:1.14" already present on machine Normal Created 38s kubelet Created container nginx Normal Started 38s kubelet Started container nginx
可以看到，我们的参考 pod 在 dce-10-6-215-200节点上，配置了 pod 亲和性之后，也在 dce-10-6-215-200 节点上
关于 PodAffinity 的 preferredDuringSchedulingIgnoredDuringExecution，这里不再演示。
PodAntiAffinity
PodAntiAffinity 主要实现以运行的 Pod 为参照，让新创建的 Pod 跟参照 pod 不在一个区域中的功能。
它的配置方式和选项跟 PodAffinty 是一样的，这里不再做详细解释，直接做一个测试案例。
继续使用上个案例中目标 pod，pod-podaffinity-target.yaml
创建 pod-podantiaffinity-required.yaml，内容如下：
apiVersion: v1 kind: Pod metadata: name: pod-podantiaffinity-required namespace: zouzou spec: containers: - name: nginx image: nginx:1.14 affinity: # 亲和性设置 podAntiAffinity: #设置 pod 反亲和性 requiredDuringSchedulingIgnoredDuringExecution: # 硬限制 - labelSelector: matchExpressions: # 匹配env的值在["xxx","yyy"]中的标签 - key: podenv # 对应的是 pod 的标签，不是 node 的，上面创建参照 pod 的时候创建了一个 podenv=pro 的标签 operator: In values: ["pro"] # 反亲和性，不在和 pod 的标签 podenv=pro 的节点上 topologyKey: kubernetes.io/hostname #
创建 pod
kubectl create -f pod-podantiaffinity-required.yaml
可以看到，因为我们设置了反亲和性，创建的 pod 就没有和 podenv=pro 标签的 pod 在一台 node 机器上
污点和容忍
污点（Taints）
前面的调度方式都是站在 pod 的角度上，通过在 pod 上添加属性，来确定 pod 是否要调度到指定的 node 上，其实我们也可以站在 node 的角度上，通过在 node 上添加污点属性，来决定是否允许 pod 调度过来
node 被设置上污点之后就和 pod 之间存在了一种互斥的关系，进而拒绝 pod 调度进来，甚至可以将已经存在的 pod 驱逐出去
污点的格式为：key=value:effect，key 和 value 是污点的标签，effect 描述污点的作用，支持如下三个选项
- PreferNoSchedule：kubernetes 将尽量避免把 Pod 调度到具有该污点的 Node上，除非没有其他节点可调度
- NoSchedule：kubernetes 将不会把 Pod 调度到具有该污点的 Node 上，但不会影响当前 Node 上已存在的 Pod
- NoExecute：kubernetes 将不会把 Pod 调度到具有该污点的 Node 上，同时也会将 Node 上已存在的 Pod 驱离
使用 kubectl 设置和去除污点的命令示例如下：
# 设置污点 kubectl taint nodes node1 key=value:effect # 去除污点 kubectl taint nodes node1 key:effect- # 去除所有污点 kubectl taint nodes node1 key-
接下来，演示下污点的效果
- 准备一个节点，为了演示效果更加明显，只需要一个 master 和一个 worker 即可
- 为 node 节点设置一个污点：tag=hihi:PreferNoSchedule，然后创建 pod1
- 修改 node 节点的污点：tag=hihi:NoSchedule，然后创建 pod2
- 修改 node 节点的污点：tag=NoExecute，然后创建 pod3
# 为 node 设置污点(PreferNoSchedule) kubectl taint node dce-10-6-215-190 tag=hihi:PreferNoSchedule
查看节点 dce-10-6-215-190 的污点，使用下面命令
# 查看 dce-10-6-215-190 节点的污点 kubectl describe node dce-10-6-215-190
创建 pod
# 创建 pod，名称叫 demo1 [root@dce-10-6-215-215 tmp]# kubectl run demo1 --image=nginx:1.14 -n zouzou [root@dce-10-6-215-215 tmp# kubectl get pods -n zouzou -o wide NAME READY STATUS RESTARTS AGE IP NODE demo1-7665f7fd85-574h4 1/1 Running 0 2m24s 10.244.1.59 dce-10-6-215-190
从结果可以看到，我们创建的 pod 运行在了 dce-10-6-215-190 的节点上，虽然 dce-10-6-215-190 我们添加了污点，但污点是 tag=hihi:PreferNoSchedule，也就是尽量避免不添加到有污点的节点上，但只有这一个 worker 节点，所以也就调度到了 dce-10-6-215-190 的节点上
删除污点，创建一个新污点，不能修改
# 删除污点 tag:PreferNoSchedule- kubectl taint node dce-10-6-215-190 tag:PreferNoSchedule-
删除后，在去查看已经没有了
# 查看污点 kubectl describe node dce-10-6-215-190
设置 NoSchedule 污点
# 给 dce-10-6-215-190 节点设置污点 tag=hihi:NoSchedule kubectl taint node dce-10-6-215-190 tag=hihi:NoSchedule
查看污点
在来创建一个新 pod 查看是否可以成功创建
# 创建 pod，名称为 demo2 [root@dce-10-6-215-215 tmp]# kubectl run demo2 --image=nginx:1.14 -n zouzou [root@dce-10-6-215-215 tmp]# kubectl get pods -n zouzou -o wide NAME READY STATUS RESTARTS AGE IP NODE demo1-7665f7fd85-574h4 1/1 Running 0 2m24s 10.244.1.59 dce-10-6-215-190 demo2-544694789-6zmlf 0/1 Pending 0 21s <none> <none>
从上面可以看出，我们新创建的 pod demo2 没有创建成功，但 demo1 还是正常运行的，因为我们创建的污点是 tag=hihi:NoSchedule（kubernetes 将不会把 Pod 调度到具有该污点的 Node 上，但不会影响当前 Node 上已存在的 Pod）
删除污点，创建一个新污点，不能修改
# 删除污点 kubectl taint node dce-10-6-215-190 tag:NoSchedule-
删除后，在去查看已经没有了
# 查看污点 kubectl describe node dce-10-6-215-190
设置 NoExecute 污点
# 给 dce-10-6-215-190 节点设置污点 tag=hihi:NoExecute kubectl taint node dce-10-6-215-190 tag=hihi:NoExecute
查看污点，污点已经设置成功了
在来创建一个新 pod 查看是否可以成功创建
# 创建 pod，名称叫 demo3 [root@dce-10-6-215-215 tmp]# kubectl run demo3 --image=nginx:1.14 -n zouzou [root@dce-10-6-215-215 tmp]# kubectl get pods -n zouzou -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED demo1-7665f7fd85-htkmp 0/1 Pending 0 35s <none> <none> <none> demo2-544694789-bn7wb 0/1 Pending 0 35s <none> <none> <none> demo3-6d78dbd749-tktkq 0/1 Pending 0 6s <none> <none> <none>
从上面结果可以看出，pod demo3 没有创建成功，而之前成功的 pod demo1 也被移除了，这是因为我们设置的污点是 tag=hihi:NoExecute（不会把 Pod 调度到具有该污点的 Node 上，同时也会将 Node 上已存在的 Pod 驱离）
使用 kubeadm 搭建的集群，默认就会给 master 节点添加一个污点标记,所以 pod 就不会调度到 master 节点上
容忍（Toleration）
上面介绍了污点的作用，我们可以在 node 上添加污点用于拒绝 pod 调度上来，但是如果就是想将一个 pod 调度到一个有污点的 node 上去，这时候应该怎么做呢？这就要使用到容忍
污点就是拒绝，容忍就是忽略，Node 通过污点拒绝 pod 调度上去，Pod 通过容忍忽略拒绝
下面先通过一个案例看下效果：
- 上面，已经在 dce-10-6-215-190 节点上打上了
NoExecute的污点，此时 pod 是调度不上去的 - 可以通过给 pod 添加容忍，然后将其调度上去
创建 pod-toleration.yaml 内容如下，先创建个不添加容忍的，创建 pod 查看效果，在创建个添加了容忍的，创建 pod，查看效果
apiVersion: v1 kind: Pod metadata: name: pod-toleration namespace: dev spec: containers: - name: nginx image: nginx:1.17.1 tolerations: # 添加容忍，下面的意思就是：tag=hihi:NoExecute - key: "tag" # 要容忍的污点的key operator: "Equal" # 操作符，Equal 为等于 value: "hihi" # 容忍的污点的value effect: "NoExecute" # 添加容忍的规则，这里必须和标记的污点规则相同
# 添加容忍之前的pod [root@dce-10-6-215-215 tmp]# kubectl get pods -n zouzou -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED pod-toleration 0/1 Pending 0 3s <none> <none> <none> # 添加容忍之后的pod [root@dce-10-6-215-215 tmp]# kubectl get pods -n zouzou -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED pod-toleration 1/1 Running 0 3s 10.244.1.62 dce-10-6-215-190 <none>
可以看到，添加了容忍之后，节点有 node，也可以创建成功
下面看一下容忍的详细配置
[root@dce-10-6-215-215 tmp]# kubectl explain pod.spec.tolerations ...... FIELDS: key # 对应着要容忍的污点的键，空意味着匹配所有的键 value # 对应着要容忍的污点的值 operator # key-value 的运算符，支持 Equal 和 Exists（默认），Exists 是存在的意思，只判断 key，不需要写 value，只要 key 存在就行 effect # 对应污点的effect，空意味着匹配所有影响 tolerationSeconds # 容忍时间, 当 effect 为 NoExecute 时生效，表示之前在你 node 节点上的 pod 的停留时间，超过了这个时间，node 就会将 pod 移除
删除多个污点
上面我们 dce-10-6-215-190 已经有一个污点了，接下来在添加一个污点
上面节点上已经有两个污点了，可以使用下面命令删除相同 key 的污点
# 删除相同 key 的污点，这里删除 key=tag 的污点 kubectl taint nodes dce-10-6-215-190 tag-
