一、Affinity概述
### --- Affinity:亲和力概述
~~~ 之前容器部署都是随机去部署的,是通过一系列的算法来筛选出最优的节点,
~~~ 来定义部署在哪个节点上面。
~~~ 虽然NodeSelect和taind可以执行这些操作,但是功能不够强大,不够灵活。
~~~ Affinity和NodeSelect功能相似,Affinity包含了NodeSelect所有的功能,
~~~ 而且比NodeSelect更加强大;而且Affinity不只是node节点上的Affinity,
~~~ 还有容器节点和Pod之间的Affinity
### --- NodeAffinity:节点亲和力,
~~~ 让pod满足一些条件去调度,这个和NodeSelect有点相似。
~~~ 因为NodeSelect只能强制的把这个Pod部署在指定的节点上面。
~~~ 但是Affinity是通过判断来必须/尽量部署在满足条件的节点
### --- Affinity类型:Affinity也分为两种:硬亲和力,软亲和力
~~~ # RequiredDuringSchedulingIgnoredDuringExecution:
~~~ 硬亲和力,即支持必须部署在指定的节点上,也支持必须不部署在指定的节点上。
~~~ # PreferredDuringSchedulingIgnoredDuringExecution:
~~~ 软亲和力,尽量部署在满足条件的节点上,或者是尽量不要部署在被匹配的节点。
~~~ # a=b:标签:若是你在required部署了a=b的标签;
~~~ 必须要部署在有这个label的node节点上面,或者是必须不部署在这个节点上面,
~~~ # a=b:但是若是你配置了preferred它就是尽量部署在a=b的这个标签的节点上面
~~~ # a=b:若是没有满足a=b;就根据其它的策略部署在其它的节点上面。
~~~ # ssd节点:存储的pod:storage-test:它要部署在有ssd节点上面,
~~~ 但是如果你的ssd节点都宕机了,它就不能部署在这个节点上面;
~~~ 但是其它的节点也不能满足这个条件,其它节点也部署不了。
~~~ 若是配置了Preferred,它会根据调度策略,部署在其它的最优的节点上面。
### --- PodAffinity:Pod亲和力
~~~ A应用B应用C应用,将A应用根据某种策略尽量或者部署在一块。Label
~~~ A:app=a B:app=b
~~~ PodAffinity也分为2种
~~~ RequiredDuringSchedulingIgnoredDuringExecution:将A应用和B应用部署在一块
~~~ PreferredDuringSchedulingIgnoredDuringExecution:尽量将A应用和B应用部署在一块
### --- PodAntiAffinity:Pod反亲和力(一般情况下这种情况使用比较多)
~~~ A应用B应用C应用,将A应用根据某种策略尽量或不部署在一块。Label
~~~ # RequiredDuringSchedulingIgnoredDuringExecution:
~~~ 不要将A应用与与之匹配的应用部署在一块
~~~ # PreferredDuringSchedulingIgnoredDuringExecution:
~~~ 尽量或者将A应用与与之匹配的应用部署在一块
### --- Affinity注意事项
~~~ k8s官方建议若是你的节点数超过1000或者好几百的话,
~~~ 不建议使用Affinity,因为它的调度时间会加长。
~~~ 需要经过一系列的计算才能把Pod部署在节点上面。
~~~ 官方优化策略:针对只对部分节点进行筛选;可以提高调度时间。
二、Affinity:NodeAffinity节点亲和力
### --- 节点亲和力官网地址:
~~~ https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/
![](https://i-blog.csdnimg.cn/blog_migrate/ba30e35e31164deb168b32b3753d51b7.png)