k8s学习笔记-调度之Affinity
Kubernetes中的調(diào)度策略可以大致分為兩種
一種是全局的調(diào)度策略，要在啟動調(diào)度器時配置，包括kubernetes調(diào)度器自帶的各種predicates和priorities算法，具體可以參看上一篇文章；
另一種是運行時調(diào)度策略，包括nodeAffinity（主機親和性），podAffinity（POD親和性）以及podAntiAffinity（POD反親和性）。
nodeAffinity?主要解決POD要部署在哪些主機，以及POD不能部署在哪些主機上的問題，處理的是POD和主機之間的關(guān)系。
podAffinity?主要解決POD可以和哪些POD部署在同一個拓撲域中的問題（拓撲域用主機標(biāo)簽實現(xiàn)，可以是單個主機，也可以是多個主機組成的cluster、zone等。）
podAntiAffinity主要解決POD不能和哪些POD部署在同一個拓撲域中的問題。它們處理的是Kubernetes集群內(nèi)部POD和POD之間的關(guān)系。
三種親和性和反親和性策略的比較如下表所示：
| 策略名稱 | 匹配目標(biāo) | 支持的操作符 | 支持拓撲域 | 設(shè)計目標(biāo) |
| nodeAffinity | 主機標(biāo)簽 | In，NotIn，Exists，DoesNotExist，Gt，Lt | 不支持 | 決定Pod可以部署在哪些主機上 |
| podAffinity | Pod標(biāo)簽 | In，NotIn，Exists，DoesNotExist | 支持 | 決定Pod可以和哪些Pod部署在同一拓撲域 |
| PodAntiAffinity | Pod標(biāo)簽 | In，NotIn，Exists，DoesNotExist | 支持 | 決定Pod不可以和哪些Pod部署在同一拓撲域 |
親和性：應(yīng)用A與應(yīng)用B兩個應(yīng)用頻繁交互，所以有必要利用親和性讓兩個應(yīng)用的盡可能的靠近，甚至在一個node上，以減少因網(wǎng)絡(luò)通信而帶來的性能損耗。
反親和性：當(dāng)應(yīng)用的采用多副本部署時，有必要采用反親和性讓各個應(yīng)用實例打散分布在各個node上，以提高HA。
主要介紹kubernetes的中調(diào)度算法中的Node affinity和Pod affinity用法
實際上是對前文提到的優(yōu)選策略中的NodeAffinityPriority策略和InterPodAffinityPriority策略的具體應(yīng)用。
kubectl explain pods.spec.affinity?
親和性策略（Affinity）能夠提供比NodeSelector或者Taints更靈活豐富的調(diào)度方式，例如：
豐富的匹配表達式（In, NotIn, Exists, DoesNotExist. Gt, and Lt）
軟約束和硬約束（Required/Preferred）
以節(jié)點上的其他Pod作為參照物進行調(diào)度計算
親和性策略分為NodeAffinityPriority策略和InterPodAffinityPriority策略。
先回顧一下之前的節(jié)點選擇器
節(jié)點選擇器： nodeSelector nodeName
創(chuàng)建一個Pod 節(jié)點選擇器標(biāo)簽
nodeSelector:
? ?disktype: ssd
默認節(jié)點沒這個標(biāo)簽：所以會調(diào)度失敗
[root@k8s-master schedule]# kubectl get node --show-labels|egrep disktype
[root@k8s-master schedule]# kubectl get pods
NAME? ? ? ? ? READY? ? ? STATUS? ? ? RESTARTS? AGE
pod-demo? ? ? ? 0/1? ? ? ? Pending? ? ? ? ? ?0? ? ? ? ? 11s
[root@k8s-master schedule]# kubectl describe pod pod-demo
Warning FailedScheduling 28s (x2 over 28s) default-scheduler 0/3 nodes are available: 3 node(s) didn't match node selector.
給一個節(jié)點打上標(biāo)簽：
[root@k8s-master schedule]# kubectl label nodes k8s-node2 disktype=ssd
node/k8s-node2 labeled
[root@k8s-master schedule]# kubectl get node --show-labels|egrep disktype
k8s-node2 Ready <none> 63d v1.14.1 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,disktype=ssd,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-node2,kubernetes.io/os=linux
[root@k8s-master schedule]# kubectl get pods -o wide
NAME? ? ? ? ? READY? ? ? ? ? STATUS? ? ? ? ?RESTARTS AGE? ? ?IP? ? ? ? ? ? ?NODE? ? ? ? ? ? NOMINATED NODE? READINESS GATES
pod-demo? ? ? ?1/1? ? ? ? ? ? ? ?Running? ? ? ? ? ? ?0? ? ? ? ? 45s? 10.244.1.14? ?k8s-node2? ? ? ? ? ? ? ? ?<none>? ? ? ? ? ? ? <none>
Node affinity（節(jié)點親和性）
kubectl explain pods.spec.affinity.nodeAffinity?
據(jù)官方說法未來NodeSeletor策略會被廢棄，由NodeAffinityPriority策略中requiredDuringSchedulingIgnoredDuringExecution替代。
NodeAffinityPriority策略和NodeSelector一樣，通過Node節(jié)點的Label標(biāo)簽進行匹配，匹配的表達式有：In, NotIn, Exists, DoesNotExist. Gt, and Lt。
定義節(jié)點親和性規(guī)則有2種：硬親和性（require）和軟親和性（preferred）
硬親和性：requiredDuringSchedulingIgnoredDuringExecution
軟親和性：preferredDuringSchedulingIgnoredDuringExecution
- 硬親和性：實現(xiàn)的是強制性規(guī)則，是Pod調(diào)度時必須滿足的規(guī)則，否則Pod對象的狀態(tài)會一直是Pending
- 軟親和性：實現(xiàn)的是一種柔性調(diào)度限制，在Pod調(diào)度時可以盡量滿足其規(guī)則，在無法滿足規(guī)則時，可以調(diào)度到一個不匹配規(guī)則的節(jié)點之上。
需要注意的是preferred和required后半段字符串IgnoredDuringExecution表示：
在Pod資源基于節(jié)點親和性規(guī)則調(diào)度到某個節(jié)點之后，如果節(jié)點的標(biāo)簽發(fā)生了改變，調(diào)度器不會講Pod對象從該節(jié)點上移除，因為該規(guī)則僅對新建的Pod對象有效。
硬親和性
kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution
apiVersion: v1
kind: Pod
metadata:
? ? name: nodeaffinity-required?
spec:
???containers:
? -? name: myapp
? ? ? image: ikubernetes/myapp:v1
? ?affinity:
? ? ?nodeAffinity:
? ? ? ? requiredDuringSchedulingIgnoredDuringExecution:
? ? ? ? ? nodeSelectorTerms:
? ? ? ? ? -? matchExpressions:
? ? ? ? ?#? ?-? {key: zone,operator: In,values: ["ssd","hard"]}? ??
? ? ? ? ? ? ? -? key: disktype
? ? ? ? ? ? ? ? ?operator: In
? ? ? ? ? ? ? ? ?values:
? ? ? ? ? ? ? ? ?-? ssd
? ? ? ? ? ? ? ? ?-? hard
[root@k8s-master schedule]# kubectl get pod -o wide
NAME? ? ? ? ? ? ? ? ? ? ? ? READY? ? ? ? ?STATUS? ? ? ? ? ? ? RESTARTS? ? ? AGE? ? ? IP? ? ? ? ? ? ? ?NODE? ? ? ? ? ? ?NOMINATED NODE? ? READINESS GATES
pod-affinity-required? ? ?1/1? ? ? ? ? ? ? ?Running? ? ? ? ? ? ? ? ? 0? ? ? ? ? ? ? ?7s? ? 10.244.1.16? ? ?k8s-node2? ? ? ? ? ? ? <none>? ? ? ? ? ? ? ? ? ?<none>
發(fā)現(xiàn)和上面定義的節(jié)點選擇器效果一樣，未來是要取代節(jié)點選擇器的。
注意：
nodeSelectorTerms可以定義多條約束，只需滿足其中一條。
? ? matchExpressions可以定義多條約束，必須滿足全部約束。
如下配置清單，必須存在滿足標(biāo)簽zone=foo和ssd=true的節(jié)點才能夠調(diào)度成功
affinity:
? ?nodeAffinity:
? ? ? requiredDuringSchedulingIgnoredDuringExecution:
? ? ? ? ?nodeSelectorTerms:
? ? ? ? ?-? matchExpressions:
? ? ? ? ? ? ?-? {key: zone, operator: In, values: ["foo"]}
? ? ? ? ?? ? -? {key: ssd, operator: Exists, values: []} #增加一個規(guī)則
[root@k8s-master ~]# kubectl get pods?pod-affinity-required
NAME? ? ? ? ? ? ? ? ? ? ? ? ? ?READY? ? ? ?STATUS? ? ?RESTARTS? ? AGE
pod-affinity-required? ? ???0/1? ? ? ? ? ? Pending? ? ? ? ? 0? ? ? ? ? ? ?16s
[root@k8s-master ~]# kubectl label node k8s-node1 ssd=true
[root@k8s-master ~]# kubectl get pods??pod-affinity-required?
NAME? ? ? ? ? ? ? ? ? ? ? ? ? ? ?READY? ? ? ? ?STATUS? ? ? ?RESTARTS AGE
?pod-affinity-required? ? ? ? ?1/1? ? ? ? ? ? ? Running? ? ? ? ? ?0? ? ? ? ? 2m
軟親和性
kubectl explain pods.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution
affinity:
? nodeAffinity:
? ? preferredDuringSchedulingIgnoredDuringExecution:
? ? -? weight:? 60
? ? ? ? preference:
? ? ? ? ? matchExpressions:
? ? ? ? ? -? {key: zone, operator: In, values: ["foo"]}
? ? -? weight:? 30
? ? ? ? preference:
? ? ? ? ? matchExpressions:
? ? ? ? ? -? {key: ssd, operator: Exists, values: []}
總結(jié)：
- 同時指定nodeSelector?and?nodeAffinity，pod必須都滿足
- nodeAffinity有多個nodeSelectorTerms?，pod只需滿足一個
- nodeSelectorTerms多個matchExpressions?，pod必須都滿足
- 由于IgnoredDuringExecution，所以改變labels不會影響已經(jīng)運行pod
總的來說，node親和性與nodeSelector類似，是它的擴展，節(jié)點是否配置合乎需求的標(biāo)簽，或者Pod對象定義合理的標(biāo)簽選擇器，這樣才能夠基于標(biāo)簽選擇出期望的目標(biāo)節(jié)點
Pod affinity（Pod 親和性）
kubectl explain pods.spec.affinity.podAffinity
在出于高效通信的需求，有時需要將一些Pod調(diào)度到相近甚至是同一區(qū)域位置（比如同一節(jié)點、機房、區(qū)域）等等，比如業(yè)務(wù)的前端Pod和后端Pod，
此時這些Pod對象之間的關(guān)系可以叫做親和性。同時出于安全性的考慮，也會把一些Pod之間進行隔離，此時這些Pod對象之間的關(guān)系叫做反親和性。
調(diào)度器把第一個Pod放到任意位置，然后和該Pod有親和或反親和關(guān)系的Pod根據(jù)該動態(tài)完成位置編排，這就是Pod親和性和反親和性調(diào)度的作用。
Pod的親和性定義也存在硬親和性和軟親和性的區(qū)別，其約束的意義和節(jié)點親和性類似。
requiredDuringSchedulingIgnoredDuringExecution， 硬約束，一定要滿足，Pod的親和性調(diào)度必須要滿足后續(xù)定義的約束條件。
preferredDuringSchedulingIgnoredDuringExecution，軟約束，不一定滿足，Pod的親和性調(diào)度會盡量滿足后續(xù)定義的約束條件。
Pod的親和性調(diào)度要求各相關(guān)的Pod對象運行在同一位置，而反親和性則要求它們不能運行在同一位置。這里的位置實際上取決于節(jié)點的位置拓撲，拓撲的方式不同，Pod是否在同一位置的判定結(jié)果也會有所不同。
如果基于各個節(jié)點的kubernetes.io/hostname標(biāo)簽作為評判標(biāo)準(zhǔn)，那么會根據(jù)節(jié)點的hostname去判定是否在同一位置區(qū)域。
根據(jù)節(jié)點上正在運行的pod的標(biāo)簽來調(diào)度，而非node的標(biāo)簽，要求對節(jié)點和Pod兩個條件進行匹配，其規(guī)則為：如果在具有標(biāo)簽X的Node上運行了一個或多個符合條件Y的Pod，那么Pod應(yīng)該運行在此Node上，
如果是互斥，則拒絕運行在此Node上。 也就是說根據(jù)某個已存在的pod，來決定要不要和此pod在一個Node上，在一起就需要設(shè)置親和性，不和它在一起就設(shè)置互斥性。
Pod親和性調(diào)度請使用：podAffinity，非親和性調(diào)度請使用：podAntiAffinity。
InterPodAffinityPriority策略有podAffinity和podAntiAffinity兩種配置方式。
InterPodAffinityPriority是干嘛的呢？簡單來說，就說根據(jù)Node上運行的Pod的Label來進行調(diào)度匹配的規(guī)則，匹配的表達式有：In, NotIn, Exists, DoesNotExist，通過該策略，可以更靈活地對Pod進行調(diào)度。
例如：將多實例的Pod分散到不通的Node、盡量調(diào)度A-Pod到有B-Pod運行的Node節(jié)點上等等。另外與Node-affinity不同的是：該策略是依據(jù)Pod的Label進行調(diào)度，所以會受到namespace約束。
硬親和性
通過Kubernetes內(nèi)置節(jié)點標(biāo)簽中的key來進行聲明，這個key的名字為topologyKey，用來表達節(jié)點所屬的拓樸結(jié)構(gòu)之下。
pod的親和性表達方式與Node親和性是一樣的表達方式。
kubectl explain pods.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution
參數(shù)配置說明：
kubectl -get nodes --show-labels
? kubernetes內(nèi)置標(biāo)簽：
? ? ? ? ○ kubernetes.io/hostname
? ? ? ? ○ failure-domain.beta.kubernetes.io/zone
? ? ? ? ○ failure-domain.beta.kubernetes.io/region
? ? ? ? ○ beta.kubernetes.io/instance-type
? ? ? ? ○ beta.kubernetes.io/os
? ? ? ? ○ beta.kubernetes.io/arch
topologyKey:
1:創(chuàng)建參照Pod
#查看調(diào)度到哪個Node之上：
kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
pod-flag 1/1 Running 0 4m 10.244.1.16 k8s-node1
2:創(chuàng)建一個pod的硬親和性
# 因為pod是屬于某個命名空間的，所以設(shè)置符合條件的目標(biāo)Pod時，還可以指定哪個命名空間或全部命名空間里的Pod，
# namespace的定義與labelSelector同級，如果不指定命名空間，則與此處創(chuàng)建的pod在一個namespace之中
kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
with-pod-affinity 1/1 Running 0 11s 10.244.1.16 k8s-node1
pod-flag 1/1 Running 0 1h 10.244.1.17 k8s-node1
的確是在同一個Node上。
如果在創(chuàng)建時，pod狀態(tài)一直處于Pending狀態(tài)，很有可能是因為找不到滿足條件的Node
基于單一節(jié)點的Pod親和性相對來說使用的情況會比較少，通常使用的是基于同一地區(qū)、區(qū)域、機架等拓撲位置約束。
比如部署應(yīng)用程序（myapp）和數(shù)據(jù)庫（db）服務(wù)相關(guān)的Pod時，這兩種Pod應(yīng)該部署在同一區(qū)域上，可以加速通信的速度
3:創(chuàng)建一個pod的反硬親和性
kubectl explain pods.spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution
kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
pod-flag 1/1 Running 0 1h 10.244.1.16 k8s-node1
with-pod-affinity 1/1 Running 0 1h 10.244.1.17 k8s-node1
with-pod-antiffinity 1/1 Running 0 1m 10.244.2.11 k8s-node2
#可以看到與參照pod不在同一個node之上,達到了互斥的作用
實例：
1.借助反硬特性我們可以部署3個redis實例，并且為了提升HA，部署在不同的節(jié)點：
apiVersion: apps/v1 kind: Deployment metadata: name: redis-cache spec: selector: matchLabels: app: store replicas: 3 template: metadata: labels: app: store spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - store topologyKey: "kubernetes.io/hostname" containers: - name: redis-server image: redis:3.2-alpine2：部署三個web實例，為了提升HA，都不在一個node；并且為了方便與redis交互，盡量與redis在同一個node（硬特性和反硬特性的結(jié)合應(yīng)用）。
apiVersion: apps/v1 kind: Deployment metadata: name: web-server spec: selector: matchLabels: app: web-store replicas: 3 template: metadata: labels: app: web-store spec: affinity: podAntiAffinity: #反親和性 requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - web-store topologyKey: "kubernetes.io/hostname" podAffinity: #親和性 requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - store topologyKey: "kubernetes.io/hostname" containers: - name: web-app image: nginx:1.12-alpine軟親和性
kubectl explain pods.spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution
上述的清單配置當(dāng)中，pod的軟親和調(diào)度需要將Pod調(diào)度到標(biāo)簽為app=cache并在區(qū)域zone當(dāng)中，或者調(diào)度到app=db標(biāo)簽節(jié)點上的，但是我們的節(jié)點上并沒有類似的標(biāo)簽，
所以調(diào)度器會根據(jù)軟親和調(diào)度進行隨機調(diào)度到k8s-node1節(jié)點之上。如下：
[root@k8s-master ~]# kubectl get pods -o wide |grep myapp-with-preferred-pod-affinity
myapp-with-preferred-pod-affinity-5c44649f58-cwgcd 1/1 Running 0 1m 10.244.1.40 k8s-node01
myapp-with-preferred-pod-affinity-5c44649f58-hdk8q 1/1 Running 0 1m 10.244.1.42 k8s-node01
myapp-with-preferred-pod-affinity-5c44649f58-kg7cx 1/1 Running 0 1m 10.244.1.41 k8s-node01
pod的反軟親和度：
kubectl explain pods.spec.affinity.podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution
podAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 100podAffinityTerm:labelSelector:matchExpressions:- key: securityoperator: Invalues:- S2topologyKey: kubernetes.io/hostname 如果該節(jié)點已經(jīng)運行著具有“security=S2”標(biāo)簽的pod，將不會優(yōu)先調(diào)度到該節(jié)點。 如果topologyKey是failure-domain.beta.kubernetes.io/zone，該pod也不會被優(yōu)先調(diào)度到具有“security=S2”標(biāo)簽的節(jié)點所在的zone 實例：使用該配置模板創(chuàng)建三個pod，可以發(fā)現(xiàn)pod依舊分配到了不同的節(jié)點上。當(dāng)創(chuàng)建第四個pod時，第四個pod能夠被順利創(chuàng)建
說明preferredDuringScheduling在podAntiAnffinity下也是不嚴格匹配規(guī)則，如果是硬約束，會有一個處于?Pending?
對稱性
考慮一個場景，兩個應(yīng)用S1和S2。現(xiàn)在嚴格要求S1 pod不能與S2 pod運行在一個node，
如果僅設(shè)置S1的hard反親和性是不夠的，必須同時給S2設(shè)置對應(yīng)的hard反親和性。
即調(diào)度S1 pod時，考慮node沒有S2 pod，同時需要在調(diào)度S2 pod時，考慮node上沒有S1 pod。考慮下面兩種情況：
1.先調(diào)度S2，后調(diào)度S1，可以滿足反親和性，
2.先調(diào)度S1，后調(diào)度S2，違反S1的反親和性規(guī)則，因為S2沒有反親和性規(guī)則，所以在schedule-time可以與S1調(diào)度在一個拓撲下。
這就是對稱性，即S1設(shè)置了與S2相關(guān)的hard反親和性規(guī)則，就必須對稱地給S2設(shè)置與S1相關(guān)的hard反親和性規(guī)則，以達到調(diào)度預(yù)期。
反親和性（soft/hard）具備對稱性，上面已經(jīng)舉過例子了
hard親和性不具備對稱性，例如期望test1、test2親和，那么調(diào)度test2的時候沒有必要node上一定要有test1，但是有一個隱含規(guī)則，node上有test1更好
soft親和性具備對稱性，不是很理解，遺留
1.Pod間的親和性和反親和性需要大量的處理，需要消耗大量計算資源，會增加調(diào)度時間,這會顯著減慢大型集群中的調(diào)度。 我們不建議在大于幾百個節(jié)點的群集中使用它們。
2.Pod反親和性要求Node一致地標(biāo)記,集群中的每個節(jié)點必須具有匹配topologyKey的標(biāo)簽,Pod反親和性需要制定topologyKey如果某些或所有節(jié)點缺少指定的topologyKey標(biāo)簽，則可能導(dǎo)致意外行為。
3.在反親和性中，空的selector表示不與任何pod親和。
4.由于hard規(guī)則在預(yù)選階段處理，所以如果只有一個node滿足hard親和性，但是這個node又不滿足其他預(yù)選判斷，比如資源不足，那么就無法調(diào)度。所以何時用hard，何時用soft需要根據(jù)業(yè)務(wù)考量。
5.如果所有node上都沒有符合親和性規(guī)則的target pod，那么pod調(diào)度可以忽略親和性
6.如果labelSelector和topologyKey同級，還可以定義namespaces列表，表示匹配哪些namespace里面的pod，默認情況下，會匹配定義的pod所在的namespace，如果定義了這個字段，但是它的值為空，則匹配所有的namespaces。
7.所有關(guān)聯(lián)requiredDuringSchedulingIgnoredDuringExecution的matchExpressions全都滿足之后，系統(tǒng)才能將pod調(diào)度到某個node上。
?
?
?
?
??
轉(zhuǎn)載于:https://www.cnblogs.com/centos-python/articles/10886525.html
總結(jié)
以上是生活随笔為你收集整理的k8s学习笔记-调度之Affinity的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Linux下用mutt给QQ邮箱发匿名邮
- 下一篇： MapReduce编程实践