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

   

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

 nodeSelector(节点选择器)ubuntu

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


步骤1:为节点添加标签安全

kubectl get nodes -o wide 获取全部node信息ide

一、kubectl label nodes daily-k8s-n01 node=node01  二、kubectl label nodes daily-k8s-n01 disktype=ssd测试

为节点添加node标签node01,或者是disk类型为ssdspa


  nodeSelector只能基于节点标签控制pod部署node,而且选择器只支持“与”逻辑操做。亲和与反亲和特性目前处于测试阶段,相比于节点选择器,其更灵活,功能更强大,体如今如下三点:orm

一、不只仅是“与”,支持更多的逻辑表达式。部署

二、nodeSelector是硬性要求,亲和与反亲和支持软硬两种要求。get

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

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

节点亲和与nodeSelector类似,具有上述一、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指定调度到此节点便可

相关文章
相关标签/搜索