Kubernetes使用节点污点和pod容忍度阻止节点调度到特定节点

　　Kubernetes允许你去影响pod被调度到哪个节点。起初，只能通过在pod规范里指定节点选择器来实现，后面其他的机制逐渐加入来扩容这项功能，本章将包括这些内容。

　　现在要介绍的高级调度的两个特性是节点污点，以及pod对于污点的容忍度,这些特性被用于限制哪些pod可以被调度到某一个节点。只有当一个pod容忍某个节点的污点，这个pod才能被调度到该节点。

　　这与使用节点选择器和节点亲缘性有些许不同，节点选择器和节点亲缘性规则，是通过明确的在pod中添加的信息，来决定一个pod可以或者不可以被调度到哪些节点上。而污点则是在不修改已有pod信息的前提下，通过在节点上添加污点信息，来拒绝pod在某些节点上的部署。

1.介绍污点和容忍度

　　学习节点污点的最佳路径就是看一个己有的污点。默认情况下，这样一个集群中的主节点需要设置污点，这样才能保证只有控制面板pod才能部署在主节点上。

　　显示节点的污点信息

　　可以通过kubectl describe node查看节点的污点信息，如以下代码所示。

#代码16.1显示通过kubeadm创建的集群中的主节点信息
$ kubectl describe node master.k8s
Name：      master.k8s
Role：
Labels：    beta.kubernetes.io/arch=amd64
    　　　　 beta.kubernetes.io/os=linux
    　　    kubernetes.io/hostname=master.k8s
    　　　　 node-role.kubernetes.io/master=
Annotations： node.alpha.kubernetes.io/ttl=0
    　　　　  volumes.kubernetes.io/controller-managed-attach-detach=true
Taints：    node-role.kubernetes.io/master:NoSchedule             #主节点包含一个污点

　　主节点包含一个污点，污点包含了一个key,value,以及一个effect，表现为<key>=<value>:<effect>。上面显示的主节点的污点信息，包含一个为node-role.kubernetes.io/master的key，一个空的value,以及值为NoSchedule的effect。

　　这个污点将阻止pod调度到这个节点上面，除非有pod能容忍这个污点，而通常容忍这个污点的pod都是系统级别pod(见图16.1)。

　　显示pod的污点容忍度

　　在一个通过kubeadm初始化的集群中，kube-proxy集群组件以pod的形式运行在每个节点上，其中也包括主节点。因为以pod形式运行的主节点组件同时也需要访问Kubernetes服务。为了确保kube-proxy pod也能够运行在主节点上，该pod需要添加相应的污点容忍度。该pod整体包含了3个污点容忍度，如以下代码所示。

#代码16.2 一个pod的污点容忍度
$ kubectl describe po kube-proxy-80wqm -n kube-system
Tolerations： node-role.kubernetes.io/master=:NoSchedule
     　　　　　node.alpha.kubernetes.io/notReady=:Exists:NoExecute
     　　　　　node.alpha.kubernetes.io/unreachable=:Exists:NoExecute

　　如你所见，第一个污点容忍度匹配了主节点的污点，表示允许这个kube-proxy pod被调度到主节点上。

　　注意:尽管在pod的污点容忍度中显示了等号，但是在节点的污点信息中却没有。当污点或者污点容忍度中的value为null时，kubectl故意将污点和污点容忍度进行不同形式的显示。

　　了解污点的效果

　　另外两个在kube-proxy pod上的污点定义了当节点状态是没有ready或者是unreachable时，该pod允许运行在该节点多长时间（时间用秒来表示，这里没有显示，但是podYAML中可以看到）。这两个污点容忍度使用的效果是NoExecute而不是NoSchedule。

　　每一个污点都可以关联一个效果，效果包含了以下三种：

• • NoSchedule表示如果pod没有容忍这些污点，pod则不能被调度到包含这些污点的节点上。
  • PreferNoSchedule是NoSchedule的一个宽松的版本，表示尽量阻止pod被调度到这个节点上，但是如果没有其他节点可以调度，pod依然会被调度到这个节点上。
  • NoExecute不同于NoSchedule以及PreferNoSchedule,后两者只在调度期间起作用，而NoExecute也会影响正在节点上运行着的pod。如果在一个节点上添加了NoExecute污点，那些在该节点上运行着的pod,如果没有容忍这个NoExecute污点，将会从这个节点去除。

2.在节点上添加自定义污点

　　假设你有一个单独的Kubernetes集群，上面同时有生产环境和非生产环境的流量。其中最重要的一点是，非生产环境的pod不能运行在生产环境的节点上。可以通过在生产环境的节点上添加污点来满足这个要求，可以使用kubectl taint命令来添加污点：

$ kubectl taint node node1.k8s node-type=production:NoSchedule
node "node1.k8s" tainted

　　这个命令添加了一个taint，其中，key为node-type, value为production,效果为NoSchedule。如果现在部署一个常规pod的多个副本，会发现没有一个pod被部署到添加了污点信息的节点上面，如以下代码清单所示。

#代码16.3 部署没有污点容忍度的pod
$ kubectl run test --image busybox --replicas 5 -- sleep 99999
deployment"test"created
$ kubectl get po -o wide
NAME    　　　　　READY STATUS RESTARTS AGE 　　IP   　　NODE
test-196686-46ng1 1/1  Running  0  　　12s 10.47.0.1 node2.k8s
test-196686-73p89 1/1  Running  0  　　12s 10.47.0.7 node2.k8s
test-196686-77280 1/1  Running  0  　　12s 10.47.0.6 node2.k8s
test-196686-h9m8f 1/1  Running  0  　　12s 10.47.0.5 node2.k8s
test-196686-p85l1 1/1  Running  0  　　12s 10.47.0.4 node2.k8s

　　现在，没人能够随意地将pod部署到生产环境节点上了。

3.在pod上添加污点容忍度

　　为了将生产环境pod部署到生成环境节点上，pod需要能容忍那些添加在节点上的污点。生产环境pod的清单里面需要增加以下的YAML代码片段。

#代码16.4 标记污点容忍度的生产环境部署：production-deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: prod
spec:
  replicas: 5
  template:
    metadata:
      labels:
        app: prod
    spec:
    ...
      tolerations:
      - key: node-type                #此处的污点容忍度予许pod被调度到生产环境节点上
        operator: Equal
        value: production
        effect: NoSchedule

　　如果运行了这个部署，将看到pod就会被调度到生产环境节点，如以下代码所示。

#代码16.5 包含污点容忍度的pod被调度到生产环境节点node1
$ kubectl get po -o wide
NAME    　　　　　　READY STATUS RESTARTS 　AGE 　　IP   　　NODE
prod-350605-1ph5h 0/1  Running  0  　　　　16s 10.44.0.3 node1.k8s
prod-350605-ctqcr 1/1  Running  0  　　　　16s 10.47.0.4 node2.k8s
prod-350605-f7pcc 0/1  Running  0  　　　　17s 10.44.0.6 node1.k8s
prod-350605-k7c8g 1/1  Running  0  　　　　17s 10.47.0.9 node2.k8s
prod-350605-rp1nv 0/1  Running  0  　　　　17s 10.44.0.4 node1.k8s

　　生产环境pod也被调度到了非生产环境node2。为了防止这种情况发生，也需要在非生产环境的节点设置污点信息，例如node-type=non-production:NoSchedule。那么，也需要在非生产环境pod上添加了对应的污点容忍度。

4.了解污点和污点容忍度的使用场景

　　节点可以拥有多个污点信息，而pod也可以有多个污点容忍度。正如你所见，污点可以只有一个key和一个效果，而不必设置value。污点容忍度可以通过设置Equal操作符Equal操作符来指定匹配的value(默认情况下的操作符），或者也可以通过设置Exists操作符来匹配污点的key。

　　在调度时使用污点和容忍度

　　污点可以用来组织新pod的调度（使用NoSchedule效果），或者定义非优先调度的节点（使用PreferNoSchedule效果），甚至是将已有的pod从当前节点剔除。

　　可以用任何觉得合适的方式去设置污点和容忍度。例如，可以将一个集群分成多个部分，只允许开发团队将pod调度到他们特定的节点上。当你的部分节点提供了某种特殊硬件，并且只有部分pod需要使用到这些硬件的时候，也可以通过设置污点和容忍度的方式来实现。

　　配置节点失效之后的pod重新调度最长等待时间

　　也可以配置一个容忍度，用于当某个pod运行所在的节点变成unready或者unreachable状态时，Kubernetes可以等待该pod被调度到其他节点的最长等待时间。如果查看其中一个pod的容忍度信息，将看到两条容忍度信息，如以下代码所示。

#代码16.6 带有默认容忍度的pod
$ kubectl get po prod-350605-1ph5h -o yaml
  tolerations：
  - effect: NoExecute                          #该pod允许所在节点处于notReady状态为300秒,之后pod将被重新调度
    key: node.alpha.kubernetes.io/notReady
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute         #同样的配置应用于节点处理unreachable状态
    key: node.alpha.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300

　　这两个容忍度表示，该pod将容忍所在节点处于notReady或者unreachable状态维持300秒。当Kubernetes控制器检测到有节点处于notReady或者unreachable状态时，将会等待300秒，如果状态持续的话，之后将把该pod重新调度到其他节点上。

　　当没有定义这两个容忍度时，他们会自动添加到pod上。如果你觉得对于你的pod来说，5分钟太长的话，可以在pod描述中显式地将这两个容忍度设置得更短一些。

　　注意:在1.8之前这是一个alpha阶段的特性，在未来的Kubernetes版本中可能会有所改变。基于污点信息的pod剔除也不是默认启用的，如果要启用这个特性，需要在运行控制器管理器时使用--feature-gates=TaintBasedEvictions=true选项。

5.小结

　　污点可以让pod远离特定的节点。污点就是在不修改已有pod信息的前提下，通过在节点上添加污点信息，来拒绝pod在某些节点上的部署。