本文主要快速講解Kube.NETes的親和性調度 和 反親和性調度，通過理論結合實際的方式，讓理解更深刻。
首先來個一句話總結：親和性調度就像關系親密的閨蜜，你去哪兒我也去哪兒。反親和性調度就像賭氣的兩個孩子，賭氣永遠不在一起玩兒。更多解釋和實戰詳見下文?；?0分鐘看到最后，你肯定會有收獲。
一、調度Pod的主要方式
Pod調度到指定Node的方式主要有4種：
- nodeName調度：直接在Pod的yaml編排文件中指定nodeName，調度到指定name的節點上。
- nodeSelector調度：直接在Pod的yaml編排文件中指定nodeSelector，調度到帶有指定label的節點上。
- 污點(TAInts)和容忍度(Tolerations)調度：詳見文章《5分鐘搞懂K8S的污點和容忍度(理論+實戰)》。主要通過在Node節點上打污點，然后在Pod的yaml編排文件中配置容忍度，來實現調度。
- 親和-反親和調度：見下文講解。
二、為什么需要親和調度
有了nodeName調度、nodeSelector調度、污點(Taints)和容忍度(Tolerations)調度，為什么還需要親和-反親和調度呢？
為了更靈活更復雜的調度方式。比如有些場景想把2個Pod 調度到一臺節點上，有的場景為了隔離性高可用性想把2個Pod分開到不同節點上，或者有的場景想把Pod調度到指定的一些特點節點上。
三、親和調度的前置概念（重要）
label在K8S中是非常重要的概念，不管是什么場景，只要和選擇、篩選相關的，基本是用label字段來匹配的。
親和性和反親和性的調度，篩選的條件依舊用的是Node的label字段。
不管是Node親和性調度，還是Pod親和性調度，被調度的主體都是Pod。都是講的Pod根據親和規則調度到某個節點，或者Pod跟隨別的Pod調到到某個節點（比如Pod1跟隨Pod2，Pod2被調度到B節點，那么Pod1也被調度到B節點）。
Node親和性調度 和 Pod親和性調度 的配置都是寫在 編排Pod的yaml里。因為被調度的主體是Pod。
Node親和性調度是指Pod和Node的親密關系。
Pod親和性調度是指Pod和Pod的親密關系。
- 硬親和：親和規則只有一種，必須符合該規則。
- 軟親和：規則有多種，每個權重不同，根據權重優先級去選擇一個規則。
Node親和性調度的圖示如下，Pod親和性調用和Pod反親和性調用也類似。
四、親和調度的具體概念
Affinity的中文意思是親近，用來表述親和性調度再合適不過了。
親和性調度：就好像Node（或者Pod）和Pod是關系很好的閨蜜，Pod說，“只要符合這種label的Node（Pod）都是我的好閨蜜，閨蜜在哪兒我就去哪兒”。
反親和性調度：就好像2個Pod是賭氣的2個孩子，互相對著干，一個往東，另一隨便去哪個方向就是不往東，他們不會去到同一個地方。
1.記住這三種調度關系
親和性調度 和 反親和性調度的關系就三種：
- node親和調度：硬親和、軟親和
- pod親和調度：硬親和、軟親和
- pod反親和調度：硬親和、軟親和
2.記住這2種親和表達式
不管是Node親和 還是Pod親和，他們都有2種親和性表達方式：
- RequiredDuringSchedulingIgnoredDuringExecution：是硬親和的方式，必須滿足指定的規則才可以把Pod調度到該Node上。這里注意Required這個詞，中文意思必須的。
- PreferredDuringSchedulingIgnoredDuringExecution：是軟親和的方式，強調優先滿足某個規則，然后根據優先的規則，將Pod調度到節點上。這里注意Preferred這個詞，中文意思是首選，用來說明選擇規則的優先級，確實比較合適。
這兩個字段也比較長，我們來做下拆解，將RequiredDuringSchedulingIgnoredDuringExecution拆解為RequiredDuringScheduling和IgnoredDuringExecution。
- RequiredDuringScheduling：定義的規則必須強制滿足（Required）才會把Pod調度到節點上。
- IgnoredDuringExecution：已經在節點上運行的Pod不需要滿足定義的規則，即使去除節點上的某個標簽，那些需要節點包含該標簽的Pod依舊會在該節點上運行?；蛘哌@么理解：如果Pod所在的節點在Pod運行期間標簽被刪除了，不再符合該Pod的節點親和性規則，那也沒關系，該Pod 還能繼續在該節點上運行。
3.表達式中的操作符
親和性表達方式需要用到如下幾個可選的操作符operator：
- In：標簽的值在某個列表中
- NotIn：標簽的值不在某個列表中
- Exists：存在某個標簽
- DoesNotExist：不存在某個標簽
- Gt：標簽的值大于某個值（字符串比較）
- Lt：標簽的值小于某個值（字符串比較）
這些操作符里，雖然沒有排斥某個節點的功能，但是用這幾個標簽也可以變相的實現排斥的功能。
4.作用域topologyKey
topologyKey很多地方解釋為拓撲建，很是費解。實際上就是個作用域的概念。
topologyKey配置了一個label的key，那么存在這個key對應的label的所有Node就在同一個作用域里。
五、實戰
理論知識講解完畢，接下來通過實戰加深理解。你可以按照步驟操作實踐。
1.nodeName調度
比如要將Pod調度到nodeName是k8s-worker-2的節點上
apiVersion: v1
kind: Pod
metadata:
name: webApp
namespace: demo
labels:
app: webapp
spec:
nodeName: 'k8s-worker-2'
containers:
- name: webapp
image: Nginx
ports:
- containerPort: 80
2.nodeSelector調度
比如要將Pod調度到具有"special-app"="specialwebapp"的label節點上。
查看節點信息：
kubectl describe node k8s-worker-2
Pod的yaml編排文件：
apiVersion: v1
kind: Pod
metadata:
name: webapp
namespace: demo
labels:
app: webapp
spec:
nodeSelector:
# 選擇調度到具有這個label的節點
"special-app": "specialwebapp"
containers:
- name: webapp
image: nginx
ports:
- containerPort: 80
查看Pod被調度到哪臺機器上：
kubectl get pod -n demo -o wide
3.Node親和調度
Node的親和調度是指，Node和Pod的關系。
(1) 硬親和
定義Pod-Node的硬親和yaml文件：pod_node_required_affinity.yaml。文件內容如下：
apiVersion: v1
kind: Pod
metadata:
name: webapp
namespace: demo
labels:
app: webapp
spec:
containers:
- name: webapp
image: nginx
ports:
- containerPort: 80
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: app
operator: In
values:
- backend
給k8s-worker-3節點添加label：
kubectl label node k8s-worker-3 app=backend
查看k8s-worker-3節點的label情況：
kubectl get node k8s-worker-3 --show-labels
執行上面的yaml部署Pod，可以看到Pod已經被調度到k8s-worker-3節點上。
(2) 軟親和
軟親和調度，主要就是加入了多個規則，每個設置了權重，yaml文件如下：
apiVersion: v1
kind: Pod
metadata:
name: webapp
namespace: demo
labels:
app: webapp
spec:
containers:
- name: webapp
image: nginx
ports:
- containerPort: 80
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 80
preference:
matchExpressions:
- key: app2
operator: Exists
- weight: 20
preference:
matchExpressions:
- key: app
operator: In
values:
- backend2
刪除之前的Pod，刪除之前的k8s-worker-3節點的label，再給k8s-worker-2節點的增加app2=backend的label。
kubectl delete pod webapp -n demo
kubectl label node k8s-worker-3 app-
kubectl label node k8s-worker-2 app2=backend
部署上面的軟親和yaml文件，可以看到Pod被調度到了k8s-worker-2節點。
4.Pod親和調度
Pod親和調度，是指Pod和Pod之間的關系。
(1) 硬親和
比如Pod1跟隨Pod2，Pod2被調度到B節點，那么Pod1也被調度到B節點。
所以這里準備2個Pod。Pod1使用上面的例子，讓Pod1采用Node硬親和調度到k8s-worker-3節點。然后再部署Pod2，讓它跟隨Pod1，也會被調度到k8s-worker-3節點。
準備Pod2的yaml編排文件pod_pod_required_affinity.yaml，如下：
apiVersion: v1
kind: Pod
metadata:
name: webapp-1
namespace: demo
labels:
app: webapp-1
spec:
containers:
- name: webapp
image: nginx
ports:
- containerPort: 80
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: kubernetes.io/hostname
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- webapp
可以看到Pod2跟隨Pod1，也被調度到了k8s-worker-3節點。
(2) 軟親和
軟親和和硬親和類似，只是多了權重，你可以自行嘗試。
5.Pod反親和調度
(1) 反親和的硬親和
接著上面的例子，繼續準備Pod3的yaml編排文件，如下：
apiVersion: v1
kind: Pod
metadata:
name: webapp-2
namespace: demo
labels:
app: webapp-2
spec:
containers:
- name: webapp
image: nginx
ports:
- containerPort: 80
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: kubernetes.io/hostname
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- webapp
使用Pod反親和的方式，讓Pod3和Pod1不會部署在一起。部署完畢后，查看結果，Pod3因為反親和被調度到了k8s-worker-2節點。
(2) 反親和的軟親和
反親和的軟親和 和 硬親和類似，只是多了權重，你可以自行嘗試。
六、總結
本文主要快速講解Kubernetes的親和性和反親和性調度。讀完本文你需要記住以下3點：
- 親和性 和 反親和性的調度，篩選的條件使用的是Node（Pod）的label字段。
- 親和性調度：就好像Node（Pod）和Pod是關系很好的閨蜜，Pod說，“只要符合這種label的Node（Pod）都是我的好閨蜜，閨蜜在哪兒我就去哪兒”。
- 反親和性調度：就好像2個Pod是賭氣的2個孩子，互相對著干，一個往東，另一隨便去哪個方向就是不往東，他們不會去到同一個地方。
