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-46ngl 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-p85ll 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在某些节点上的部署。