本文永久鏈接:?https://www.xtplayer.cn/kubernetes/scheduler/influencing-kubernetes-scheduler-decisions/
為了提高節(jié)點資源的最大利用率，調(diào)度程序使用復(fù)雜的算法來確保最有效的 Pod 調(diào)度睡陪。在本文中忍级，我們討論調(diào)度程序如何選擇最佳節(jié)點來運行 Pod，以及如何影響其決策。
選擇適當(dāng)?shù)墓?jié)點時，調(diào)度程序會檢查每個節(jié)點是否有足夠的資源滿足 Pod 調(diào)度馍惹。如果您已經(jīng)聲明 Pod 所需的 CPU 和內(nèi)存量（通過請求和限制）躺率，調(diào)度程序?qū)⑹褂靡韵鹿絹碛嬎憬o定節(jié)點上的可用內(nèi)存：
調(diào)度可用內(nèi)存 = 節(jié)點總內(nèi)存 - 已預(yù)留內(nèi)存
保留內(nèi)存是指：
Kubernetes 守護(hù)進(jìn)程使用的內(nèi)存玛界，例如：kubelet万矾、containerd（一種容器運行時）。
節(jié)點操作系統(tǒng)使用的內(nèi)存慎框，例如：內(nèi)核守護(hù)程序良狈。
通過使用此方程式，調(diào)度程序可確保由于過多 Pod 競爭消耗節(jié)點所有可用資源笨枯，從而導(dǎo)致節(jié)點資源耗盡引起其他系統(tǒng)異常薪丁，比如系統(tǒng)觸發(fā) oom。
在不受用戶影響的情況下馅精，調(diào)度程序在將 Pod 調(diào)度到節(jié)點時執(zhí)行以下步驟：
調(diào)度程序檢測到已創(chuàng)建新的 Pod严嗜，但尚未將其分配給節(jié)點；
它檢查 Pod 需求洲敢，并相應(yīng)地篩選出所有不合適的節(jié)點漫玄；
根據(jù)權(quán)重將剩下的節(jié)點進(jìn)行排序，權(quán)重最高的排在第一位压彭；
調(diào)度程序選擇排序列表中的第一個節(jié)點睦优，然后將 Pod 分配給它。
通常壮不，我們會讓調(diào)度程序自動選擇合適的節(jié)點（前提是 Pod 配置了資源請求和限制）汗盘。但是，有時可能需要通過強(qiáng)制調(diào)度程序選擇特定節(jié)點或手動向多個節(jié)點添加權(quán)重來影響此決策询一，以使其比其他節(jié)點更適合 Pod 調(diào)度隐孽。
讓我們看看我們?nèi)绾巫龅竭@一點：
在最簡單的節(jié)點選擇配置中，您只需在?.spec.nodeName?中指定其名稱健蕊，就可以強(qiáng)制 Pod 在指定節(jié)點上運行缓醋。例如，以下 YAML 定義 Pod 強(qiáng)制在 app-prod01 上進(jìn)行調(diào)度：
YAML
apiVersion:v1
kind:Pod
metadata:
name:nginx
spec:
containers:
-name:nginx
image:nginx
nodeName:app-prod01
請注意绊诲，由于以下原因送粱，此方法是最簡單但最不推薦的節(jié)點選擇方法：
如果由于某種原因無法找到指定名稱的節(jié)點（例如，更改了主機(jī)名）掂之，則 Pod 將不會運行抗俄。
如果該節(jié)點沒有 Pod 運行所需的資源，則 Pod 會運行失敗世舰，并且也不會將該 Pod 調(diào)度到其他節(jié)點动雹。
這會導(dǎo)致 Pods 與它們的節(jié)點緊密耦合，這是一種糟糕的設(shè)計實踐跟压。
覆蓋調(diào)度程序決策的第一個最簡單的方法是使用 Pod 定義或 Pod 模板（如果使用的是 Deployments 之類的控制器）中的?.spec.nodeSelector?參數(shù)胰蝠。nodeSelector 接受?一個或多個?鍵-值對標(biāo)簽，這些?鍵-值對?標(biāo)簽必須在節(jié)點設(shè)置才能正常的調(diào)度 Pod。假設(shè)您最近購買了兩臺配備 SSD 磁盤的計算機(jī)茸塞，您希望數(shù)據(jù)庫相關(guān)所有的 Pod 在 SSD 支持的節(jié)點上進(jìn)行調(diào)度躲庄，以獲得最佳的數(shù)據(jù)庫性能。DB Pod 的 Pod YAML 可能如下所示：
YAML
apiVersion:v1
kind:Pod
metadata:
name:db
spec:
containers:
-name:mongodb
image:mongo
nodeSelector:
disktype:ssd
根據(jù)該定義钾虐，當(dāng)調(diào)度程序選擇合適的 Pod 分配節(jié)點時噪窘，將僅考慮具有?disktype=ssd?標(biāo)簽的節(jié)點。
此外效扫，您可以使用自動分配給節(jié)點的任何內(nèi)置標(biāo)簽來操縱選擇決策倔监。例如，節(jié)點的主機(jī)名（kubernetes.io/hostname）菌仁，體系結(jié)構(gòu)（kubernetes.io/arch）浩习，操作系統(tǒng)（kubernetes.io/os）等均可用于節(jié)點選擇。
當(dāng)您需要選擇特定的節(jié)點來運行我們的 Pod 時济丘，節(jié)點選擇非常有用瘦锹。但是選擇節(jié)點的方式是有限的，只有與所有定義的標(biāo)簽匹配的節(jié)點才被考慮用于 Pod 放置闪盔。Node Affinity 通過允許您定義硬節(jié)點和軟節(jié)點需求弯院，為您提供了更大的靈活性。硬性要求必須在要選擇的節(jié)點上匹配泪掀。另一方面听绳，軟條件允許您為具有特定標(biāo)簽的節(jié)點增加更多權(quán)重，以使它們在列表中的位置比對等節(jié)點更高异赫。沒有軟需求標(biāo)簽的節(jié)點將不被忽略椅挣，但它們權(quán)重更小。
讓我們舉個例子：我們的數(shù)據(jù)庫是 I/O 密集型的塔拳。我們需要數(shù)據(jù)庫 Pods 始終在 SSD 支持的節(jié)點上運行鼠证。此外，如果 Pod 部署在區(qū)域 zone1 或 zone2 中的節(jié)點上靠抑，因為它們在物理上更靠近應(yīng)用程序節(jié)點量九，那么它們的延遲會更短。滿足我們需求的 Pod 定義可能如下所示：
YAML
apiVersion:v1
kind:Pod
metadata:
name:db
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
-matchExpressions:
-key:disk-type
operator:In
values:
-ssd
preferredDuringSchedulingIgnoredDuringExecution:
-weight:1
preference:
matchExpressions:
-key:zone
operator:In
values:
-zone1
-zone2
containers:
-name:db
image:mongo
nodeAffinity 節(jié)使用以下參數(shù)來定義硬性要求和軟性要求：
requiredDuringSchedulingIgnoredDuringExecution：部署 DB Pod 時颂碧，節(jié)點必須具有 disk-type=ssd荠列。
preferredDuringSchedulingIgnoredDuringExecution：?當(dāng)對節(jié)點進(jìn)行排序時，調(diào)度器會給予標(biāo)簽為zone=zone1或zone=zone2的節(jié)點更高的權(quán)重载城。如果有disk-type=ssd和zone=zone1的節(jié)點肌似，則優(yōu)先選擇 disk-type=ssd 且無 zone 標(biāo)簽的節(jié)點或指向其他 zone 的節(jié)點。權(quán)重可以是 1 到 100 之間的任意值诉瓦，權(quán)重號賦予匹配節(jié)點相對于其他節(jié)點更高的權(quán)重川队。數(shù)字越大力细，權(quán)值越高。
注意固额，在進(jìn)行選擇時眠蚂，節(jié)點親和性允許您在選擇目標(biāo)節(jié)點上應(yīng)該存在(或不存在)哪些標(biāo)簽時擁有更多的自由。在本例中对雪，我們使用 In 操作符定義了多個標(biāo)簽河狐，目標(biāo)節(jié)點上存在任何一個標(biāo)簽即可米绕。其他運算符是 NotIn瑟捣、Exists、doesnoexistists栅干、Lt(小于)和 Gt(大于)迈套。值得注意的是，NotIn 和 doesnot existist 實現(xiàn)了所謂的節(jié)點反親和性碱鳞。
節(jié)點親和性和節(jié)點選擇器不是互斥的桑李，它們可以共存于同一個定義文件中。但是窿给，在這種情況下贵白，節(jié)點選擇器和節(jié)點親和性硬要求必須匹配。
節(jié)點選擇器和節(jié)點親和性(以及反親和性)幫助我們影響調(diào)度器關(guān)于在何處放置 Pods 的決策崩泡。但是禁荒，它只允許您基于節(jié)點上的標(biāo)簽進(jìn)行選擇。它不關(guān)心 Pod 本身的標(biāo)簽角撞。您可能需要在以下情況下根據(jù) Pod 標(biāo)簽進(jìn)行選擇:
需要將所有中間件 Pod 放在同一個物理節(jié)點上呛伴，與那些具有 role=front 標(biāo)簽的 Pod 一起，以減少它們之間的網(wǎng)絡(luò)延遲谒所。
作為一種安全最佳實踐热康，我們不希望中間件 Pod 與處理用戶身份驗證的 Pod 共存(role=auth)。這不是一個嚴(yán)格的要求劣领。
如您所見姐军，這些要求不能用節(jié)點選擇器或親和性來滿足，因為在選擇過程中不考慮 Pod 標(biāo)簽——只考慮節(jié)點標(biāo)簽尖淘。
為了滿足這些需求庶弃，我們使用 Pod 親和性和反親和性。本質(zhì)上德澈，它們的工作方式與節(jié)點親和性和反親和性相同歇攻。必須滿足硬性要求來選擇目標(biāo)節(jié)點，而軟條件增加了擁有所選節(jié)點的機(jī)會(權(quán)重)梆造，但不是嚴(yán)格要求缴守。讓我們舉個例子:
YAML
apiVersion:v1
kind:Pod
metadata:
name:middleware
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
-labelSelector:
matchExpressions:
-key:role
operator:In
values:
-frontend
topologyKey:kubernetes.io/hostname
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
-weight:100
podAffinityTerm:
labelSelector:
matchExpressions:
-key:role
operator:In
values:
-auth
topologyKey:kubernetes.io/hostname
containers:
-name:middleware
image:redis
在上面的 Pod 定義文件中葬毫，我們對硬性要求和軟性要求進(jìn)行了如下設(shè)置：
requiredDuringSchedulingIgnoredDuringExecution：我們的 Pod 必須在具有標(biāo)簽為 app-front 的 Pod 節(jié)點上調(diào)度。
preferredDuringSchedulingIgnoredDuringExecution：我們的 Pod 不應(yīng)該(但它可以)被調(diào)度到運行帶有標(biāo)簽為 role=auth 的 Pod 的節(jié)點上屡穗。與節(jié)點親和性一樣贴捡，soft requirement 將權(quán)重從 1 設(shè)置為 100，以增加節(jié)點相對于其他節(jié)點的概率村砂。在我們的示例中烂斋，軟需求被放置在 poantiaffinity 中，導(dǎo)致運行具有標(biāo)簽為 role=auth 的 Pod 的節(jié)點在調(diào)度程序做出決定時被選中的可能性更小础废。
topologyKey?用于對規(guī)則將應(yīng)用于哪個領(lǐng)域做出更細(xì)粒度的決策汛骂。topologyKey 接受一個標(biāo)簽鍵，該標(biāo)簽鍵必須出現(xiàn)在選擇過程中考慮的節(jié)點上评腺。在我們的示例中印蔗，我們使用了自動填充的標(biāo)簽岖沛，該標(biāo)簽在默認(rèn)情況下自動添加到所有節(jié)點，并引用節(jié)點的主機(jī)名。但是您可以使用其他自動填充的標(biāo)簽俯渤，甚至是自定義的標(biāo)簽匆绣。例如啰劲，您可能需要只在具有 rack 或 zone 標(biāo)簽的節(jié)點上應(yīng)用 Pod 親和規(guī)則迁客。
關(guān)于 IgnoredDuringExecution 的注釋
您可能已經(jīng)注意到，硬需求和軟需求都有?IgnoredDuringExecution?后綴摔敛。這意味著在做出調(diào)度決策之后廷蓉，調(diào)度程序?qū)⒉粫L試更改已經(jīng)放置的 Pods，即使條件發(fā)生了變化舷夺。例如苦酱，根據(jù)節(jié)點親和性規(guī)則，將一個 Pod 調(diào)度到一個具有標(biāo)簽為 app=prod 的節(jié)點上给猾。如果該標(biāo)簽被更改為 app=dev, 舊 Pod 不會被終止疫萤，并在另一個有 app=prod 標(biāo)簽的節(jié)點上啟動新的 Pod。這個行為在將來可能會改變敢伸，以允許調(diào)度程序在部署后繼續(xù)檢查節(jié)點和 Pod 的關(guān)聯(lián)性(和反關(guān)聯(lián)性)規(guī)則扯饶。
在某些場景中，您可能希望阻止將 Pod 調(diào)度到特定節(jié)點池颈∥残颍可能您正在運行測試或掃描此節(jié)點以查找威脅，而您不希望應(yīng)用程序受到影響躯砰。節(jié)點反親和性可以實現(xiàn)這一目標(biāo)每币。但是，這是一個重大的管理負(fù)擔(dān)琢歇，因為您需要向部署到集群的每個新 Pod 添加反關(guān)聯(lián)規(guī)則兰怠。對于這種場景梦鉴，您應(yīng)該使用污點。
當(dāng)一個節(jié)點配置了污點時揭保，除非 Pod 能夠容忍這種污點肥橙，否則不能對它調(diào)度 Pod。容忍只是一個與污點匹配的鍵-值對秸侣。讓我們舉個例子來說明:
需要對主機(jī) web01 進(jìn)行污染存筏，以使其不接受更多 Pod。taint 命令如下：
YAML
kubectltaintnodesweb01locked=true:NoSchedule
上面的命令在名為 web01 的節(jié)點上放置了一個污點味榛，該節(jié)點具有以下屬性:
標(biāo)簽 locked=true椭坚，該標(biāo)簽必須配置在想要運行在該節(jié)點的 Pod 上。
NoSchedule 的污點類型励负。污點類型定義了應(yīng)用污點的行為藕溅，它有以下幾種可能:
NoSchedule：此節(jié)點一定不要調(diào)度匕得。
PreferNoSchedule：盡量不要調(diào)度继榆，類似軟親和性。
NoExecute：不僅不會調(diào)度汁掠，還會驅(qū)逐 Node 上已有的 Pod略吨。
在帶有污點的節(jié)點上，Pod 的定義文件可能如下所示:
YAML
apiVersion:v1
kind:Pod
metadata:
name:mypod
spec:
containers:
-name:mycontainer
image:nginx
tolerations:
-key:"locked"
operator:"Equal"
value:"true"
effect:"NoSchedule"
讓我們仔細(xì)看看這個定義的容忍部分:
為了具有正確的容忍考阱，我們需要指定鍵（locked）翠忠，值（true）和運算符。
運算符可以是兩個值之一：
Equal：當(dāng)使用 equal 操作符時乞榨，鍵秽之、值和污染效果必須與節(jié)點的污染匹配。
Exists：在使用 exists 操作符時吃既，不需要將污點與容忍匹配考榨，只需匹配建即可。
如果使用 Exists 運算符鹦倚，則可以忽略容忍鍵河质、值和效果。具有這種容忍的 Pod 可以被調(diào)度到具有任何受污點的節(jié)點震叙。
注意掀鹅，在 Pod 上放置容忍并不能保證它被部署到受污染的節(jié)點上。它只允許行為發(fā)生媒楼。如果要強(qiáng)制 Pod 加入受污染的節(jié)點乐尊，還必須像前面討論的那樣向其定義添加節(jié)點親和性。
在節(jié)點上自動放置 Pod 是 Kubernetes 誕生的原因之一划址。作為管理員扔嵌，只要您對 Pod 需求做出了良好的聲明昏滴，您就不用擔(dān)心節(jié)點是否有足夠的空閑資源來運行這些 Pod。但是对人，有時您必須手動干預(yù)和覆蓋系統(tǒng)關(guān)于在何處放置 Pods 的決定谣殊。在本文中，我們討論了幾種方法牺弄，在決定部署 Pods 時姻几，您可以通過這些方法對特定節(jié)點的調(diào)度器產(chǎn)生更大的影響。讓我們快速回顧一下這些方法:
節(jié)點名稱：通過將節(jié)點的主機(jī)名添加到 Pod 定義的?.spec.nodeName?參數(shù)中势告，可以強(qiáng)制此 Pod 在該特定節(jié)點上運行蛇捌。調(diào)度程序使用的任何選擇算法都將被忽略。不建議使用此方法咱台。
節(jié)點選擇器：通過在節(jié)點上放置指定的標(biāo)簽络拌，Pod 可以使用 nodeelector 參數(shù)指定一個或多個鍵-值標(biāo)簽，這些標(biāo)簽必須存在于目標(biāo)節(jié)點上才能被選中以運行 Pod回溺。推薦使用這種方法春贸，因為它增加了很多靈活性，并建立了松耦合的 node-Pod 關(guān)系遗遵。
節(jié)點親和性：在選擇應(yīng)該考慮哪個節(jié)點來調(diào)度特定的 Pod 時萍恕，這種方法增加了更多的靈活性。使用節(jié)點親和性车要，Pod 可能嚴(yán)格要求在具有特定標(biāo)簽的節(jié)點上調(diào)度允粤。它還可以通過影響調(diào)度程序為特定節(jié)點賦予更大的權(quán)重來表示對特定節(jié)點的某種程度的偏好。
Pod 親和性和反親和性：當(dāng) Pod 與同一節(jié)點上的其他 Pod 共存(或不共存)時翼岁，可以使用此方法类垫。Pod 親和性允許將 Pod 部署在具有特定標(biāo)簽的 Pod 運行的節(jié)點上。相反琅坡，Pod 可能會強(qiáng)制調(diào)度程序不將其調(diào)度到具有特定標(biāo)簽的 Pod 運行的節(jié)點上悉患。
污點和容忍：在這種方法中，您不需要決定將 Pod 調(diào)度到哪些節(jié)點脑蠕，而是決定哪些節(jié)點是否接受 所有 Pod 調(diào)度购撼，或者只接受選定的 Pod 調(diào)度。通過污染一個節(jié)點谴仙，調(diào)度程序?qū)⒉豢紤]將這個節(jié)點作為任何 Pod 的調(diào)度節(jié)點迂求，除非 Pod 配置了容忍。容忍由鍵晃跺、值和受染的效果組成揩局。
原文鏈接：https://www.magalix.com/blog/influencing-kubernetes-scheduler-decisions
