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指定调度到此节点即可
