十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
10年的资兴网站建设经验,针对设计、前端、开发、售后、文案、推广等六对一服务,响应快,48小时及时工作处理。成都全网营销的优势是能够根据用户设备显示端的尺寸不同,自动调整资兴建站的显示方式,使网站能够适用不同显示终端,在浏览器中调整网站的宽度,无论在任何一种浏览器上浏览网站,都能展现优雅布局与设计,从而大程度地提升浏览体验。创新互联建站从事“资兴网站设计”,“资兴网站推广”以来,每个客户项目都认真落实执行。
大多数情况下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 设置需保持一致, 还有以下几点说明:
如果 operator 的值是 Exists,则 value 属性可省略
如果 operator 的值是 Equal,则表示其 key 与 value 之间的关系是 equal(等于)
如果不指定 operator 属性,则默认值为 Equal
另外,还有两个特殊值:
空的 key 如果再配合 Exists 就能匹配所有的 key 与 value,也是是能容忍所有 node 的所有 Taints
空的 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指定调度到此节点即可