Kubernetes关于Affinity和nodeSelector以及Taints与容忍的理解

    大多数情况下kubernetes的调度程序能将pod调度到集群中合适的节点上。但有些情况下用户需要对pod调度到那个节点上施加更多控制，比如将pod部署到拥有SSD存储节点、将同一个服务的多个后端部署在不同的机架上提高安全性、将通信频繁的服务部署在同一个可用区域降低通信链路长度。用户对pod部署的节点施加控制都与"label selector"有关。

 nodeSelector(节点选择器)

nodeSelector也是标签选择器，是最简单、最直接控制pod部署node的方法，在daemonset用nodeSelector过滤可部署节点，以下是其普通的应用示例。

步骤1：为节点添加标签

kubectl get nodes -o wide 获取所有node信息

1、kubectl label nodes daily-k8s-n01 node=node01  2、kubectl label nodes daily-k8s-n01 disktype=ssd

为节点添加node标签node01，或者是disk类型为ssd

  nodeSelector只能基于节点标签控制pod部署node，并且选择器只支持“与”逻辑操作。亲和与反亲和特性目前处于测试阶段，相比于节点选择器，其更灵活，功能更强大，体现在以下三点：

1、不仅仅是“与”，支持更多的逻辑表达式。

2、nodeSelector是硬性要求，亲和与反亲和支持软硬两种要求。

3、除了节点标签，亲和与反亲和支持根据节点上已经部署的pod进行节点选择，这一点很重要。比如不想将两种计算密集类型的pod部署在同一节点上，后部署pod可选择过滤。

细分成两种类型的选择器："节点亲和"与"内部pod亲和、反亲和"。

节点亲和与nodeSelector相似，具备上述1、2两条优点。  内部pod亲和依赖的是节点上已有pod的标签而不是节点标签，兼俱上述三个优点。因为节点亲和能完成nodeSelector所工作并且具备额外的优点，因此nodeSelector虽然还能用，但已经不再维护，并且将来可能删除。

      NodeAffinity节点亲和性，是Pod上定义的一种属性，使Pod能够按我们的要求调度到某个Node上，而Taints则恰恰相反，它可以让Node拒绝运行Pod，甚至驱逐Pod。

 Taints(污点)是Node的一个属性，设置了Taints(污点)后，因为有了污点，所以Kubernetes是不会将Pod调度到这个Node上的， 于是Kubernetes就给Pod设置了个属性Tolerations(容忍)，只要Pod能够容忍Node上的污点，那么Kubernetes就会忽略Node上的污点，就能够(不是必须)把Pod调度过去。因此 Taints(污点)通常与Tolerations(容忍)配合使用。

设置污点：

      kubectl taint node [node] key=value[effect]   

      其中[effect] 可取值： [ NoSchedule | PreferNoSchedule | NoExecute ]

       NoSchedule ：一定不能被调度。

       PreferNoSchedule：尽量不要调度。

       NoExecute：不仅不会调度，还会驱逐Node上已有的Pod。

       示例：kubectl taint node 10.10.0.111 node=111:NoSchedule

 比如设置污点：

     kubectl taint node 10.10.0.111 node=111:NoSchedule

     kubectl taint node 10.10.0.111 node=111:NoExecute

 去除指定key及其effect：

     kubectl taint nodes node_name key:[effect]-    #(这里的key不用指定value)              

 去除指定key所有的effect: 

     kubectl taint nodes node_name key- 

 示例：

     kubectl taint node 10.10.0.111 node:NoSchedule-

     kubectl taint node 10.10.0.111 node:NoExecute-

     kubectl taint node 10.10.0.111 node-

对于 tolerations 属性的写法，其中的 key、value、effect 与 Node 的 Taint 设置需保持一致， 还有以下几点说明：

1. 如果 operator 的值是 Exists，则 value 属性可省略

2. 如果 operator 的值是 Equal，则表示其 key 与 value 之间的关系是 equal(等于)

3. 如果不指定 operator 属性，则默认值为 Equal

另外，还有两个特殊值：

1. 空的 key 如果再配合 Exists 就能匹配所有的 key 与 value，也是是能容忍所有 node 的所有 Taints

2. 空的 effect 匹配所有的 effect

      tolerations:    
        - key: "node-role.kubernetes.io/master"        
          operator: "Exists"        
          effect: "NoSchedule"
          
          
    或者：
spec:
  tolerations: #设置容忍性
  - key: "test" 
   operator: "Equal"  #如果操作符为Exists，那么value属性可省略,如果不指定operator，则默认为Equal
   value: "16"
   effect: "NoSchedule"
  #意思是这个Pod要容忍的有污点的Node的key是test Equal 16,效果是NoSchedule，
  #tolerations属性下各值必须使用引号，容忍的值都是设置Node的taints时给的值。
  containers:
   - name: pod-tains
   image: 10.3.1.15:5000/ubuntu:16.04

 通过对Taints和Tolerations的了解，可以知道，通过它们可以让某些特定应用，独占一个Node：

给特定的Node设置一个Taint，只让某些特定的应用来容忍这些污点，容忍后就有可能会被调度到此特定Node，

但是也不一定会调度给此特定Node，设置容忍并不阻止调度器调度给其它Node，那么如何让特定应用的Node

只能被调度到此特定的Node呢，这就要结合NodeAffinity节点亲和性（也可以使用nodeSelector去给node达标签的方式），然后在Pod属性里

设置NodeAffinity到Node。如此就能达到要求了。

 总结：让特定的服务跑到专属的node节点上，通过给node节点打上taints，确定不调度，然后给pod设置容忍，这样其他pod不会调度到此节点，在通过node

Selector或者NodeAffinity的方式让改pod指定调度到此节点即可