我们在使用k8s集群时候，scheduler会根据自身的调度算法，把我们的容器调度到它认为合适的node节点上，但是，在生产中，难免会有一些特殊需求：
- 1将服务调度至指定的一个node节点上，同时可以调度其它容器到该节点。
- 将服务调度至指定的拥有特殊label的一组node上。比如有一组node节点为ssd，gpu，intel cpu等。
- 将服务调度至指定的一个node节点上，并且该节点不允许其它容器调度至该节点。--某个服务独占该node节点。
- node节点下线维修，需要平滑的将该节点上的所有容器驱逐到其他node节点。
这里就需要我们人为介入，来干预调度，达到我们预期，k8s常用的有以下三种人为干预方法：
- taint和toleration -污点和容忍度方法 驱逐，排斥
- nodename -节点亲和性调度
- nodeSelector -节点亲和性调度
首先来说一下节点亲和性，2跟3这种方法就是这种原理，通过在资源配置清单中，指定node节点(一个或者一组)，来增加容器与node节点的亲和性，达到调度的预期。
节点亲和性又分为硬亲和性（required）和软亲和性（preferred），这两种的区别在于：
- 硬亲和性：强制pod运行在符合要求的node上，如果所有node都不满足，则pod处于pending状态。
- 软亲和性：调度器会尽可能的将pod调度到满足需求的node上，如果没有满足的node资源，则根据优选策略的得分值，将pod调度至其次的node上。
两种亲和性的书写方法为：
硬亲和性：
requiredDuringSchedulingIgnoredDuringExecution
软亲和性
preferredDuringSchedulingIgnoredDuringExecution
这里面后半段内容的含义为：IgnoredDuringExecution
如果节点标签发生了变化，导致该节点不在符合亲和性调度规则时，调度器不会将pod对象从此节点上移除，因为仅对新建的pod对象生效。
测试一下节点亲和性，首先测试一下硬亲和性：
创建一个资源配置清单，指定