共計 6028 個字符，預計需要花費 16 分鐘才能閱讀完成。
行業資訊
服務器
云計算
Kubernetes 高級調度中如何進行 Taint 和 Toleration、Node Affinity 分析
Kubernetes 高級調度中如何進行 Taint 和 Toleration、Node Affinity 分析，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。
(避免 Pod 和 Node 同時出現在一小段文字中, 所以 Node 以節點漢字表述)
Taint 和 Toleration
污點的理論支撐
1.1 污點設置有哪些影響效果
使用效果(Effect):
PreferNoSchedule: 調度器盡量避免把 Pod 調度到具有該污點效果的節點上, 如果不能避免(如其他節點資源不足),Pod 也能調度到這個污點節點上。
NoSchedule: 不容忍該污點效果的 Pod 永不會被調度到該節點上，通過 kubelet 管理的 Pod(static Pod)不受限制; 之前沒有設置污點的 Pod 如果已運行在此節點 (有污點的節點) 上，可以繼續運行。
NoExecute: 調度器不會把 Pod 調度到具有該污點效果的節點上，同時會將節點上已存在的 Pod 驅逐出去。
污點設置的第一前提是: 節點上的污點 key 和 Pod 上的污點容忍 key 相匹配。
1.2 設置污點的效果實測
當 Pod 未設置污點容忍而節點設置了污點時
當節點的污點影響效果被設置為:PreferNoSchedule 時, 已存在于此節點上的 Pod 不會被驅逐；新增但未設置污點容忍的 Pod 仍然可以被調度到此節點上。
當節點的污點影響效果被設置為:NoSchedule 時, 已存在于此節點上的 Pod 不會被驅逐; 同時, 新增的 Pod 不會被調度此節點上。
當節點的污點影響效果被設置為:NoExecute 時, 已存在于此節點上的 Pod 會發生驅逐(驅逐時間由 tolerationSeconds 字段確定, 小于等于 0 會立即驅逐); 新增的 Pod 不會調度到此節點上。
當 Node 設置了污點且 Pod 設置了對應的污點容忍時, 實測效果如下表：
污點容忍設置, Exists 和 Equal 這兩個操作符之間的區別是什么?
在配置上:
Exists 必須把值設置為空字符串，而只關心 key 與節點的污點 key 是否匹配。
Equal 需要同時設置 key 和 value 來匹配污點節點的 Key 和 value。
兩者之間的理解加深:
若一個節點存在多個污點, Pod 使用 Exists 只容忍了其中一個污點, 仍然不能調度此節點, 原因在于 Pod 不容忍此節點的其他污點。
若一個節點存在多個污點, Pod 使用 Equal 只容忍了其中一個污點, 仍然不能調度此節點, 原因在于 Pod 還是不容忍此節點的其他污點。
若想要一個 Pod 能夠調度到含有多個污點的節點上, 那么此 Pod 需要容忍此節點的所有污點。
1.3 污點容忍里的一些小竅門:
在污點容忍設置時, 若 key,value 是空字符且操作符是 Exists 那么能 Pod 容忍節點的所有污點。(注意: 仍然遵從于容忍效果的等級設置)。例如: 一個 Pod 在設置污點容忍時，key,value 為空且操作符是 Exists, 容忍效果為:NoExecute, 那么該 Pod 不會調度到污點效果為:NoSchedule 的節點上。
在設置污點容忍時, 若 Pod 的容忍效果 (effect) 被設置為空字符, 那么 Pod 能匹配所有的容忍效果。
在設置污點容忍時, 若 key,value 為空、操作符是 Exists 且容忍效果 (effect) 也為空時，則等于沒有設置。
默認情況下，操作符是 Equal。
如果節點的影響效果是 NoExecute, 且不想 Pod 被立即驅逐, 那么可以設置 TolerationSeconds(延遲驅逐時間), 若值是 0 或者負數會立即驅逐, 若值大于 0, 則在此時間后開始驅逐。
從測試結果來看，只要節點設置了污點且效果是:NoExecute, 不管 Pod 是否容忍了該污點都不能在對應節點上正常運行(一直處于刪除，重建的過程), 原因是能被調度到節點上是調度器選擇的結果，Pod 被殺掉是本地 kubelet 決策的結果，這是兩個組件分管不同工作產生的效果, 下面這種配置除外。
tolerations:
- operator: Exists# 此 Pod 的污點配置能夠容忍所有的污點，所有的影響效果，所有能調度到所有的節點上(包括影響效果被設置為:NoExecute 的 Node).
1.4 認知誤區
1.4.1 當一個節點設置了污點，那么只要設置 Pod 對此污點容忍就能調度上去且能正常運行。（錯）
當節點的一個污點的影響效果被設置為:NoExecute, 此時 Pod 對此污點的容忍效果也是 NoExecute 時, Pod 能調度上去，但是也會被 Terminating，不斷的處于 Terminating,ContainerCreating 的過程。
對 Node 設置污點：
kubectl taint nodes 1xx status=unavailable:NoExecutePod 設置的污點容忍：
tolerations:
- effect: NoExecute
key: status
operator: Equal
tolerationSeconds: 0
value: unavailable效果：
tolerations:
- operator: Exists# 此 Pod 的污點配置能夠容忍所有的污點，所有的影響效果，所有能調度到所有的節點上(包括影響效果被設置為:
NoExecute 的 Node).1.4.2 當一個節點設置了多個污點，只要使用 Exists 操作符匹配到其中一個污點，此 Pod 就能調度到對應的節點上。（錯）
原因在于 Pod 只能匹配到其中一個污點, 但是還是不能匹配到其他污點。所以，不能調度上去。
1.4.3 在設置 Pod 容忍時，只要匹配到 key 和 value 就行了, 不用關心容忍效果的設置。（錯）
容忍效果的設置和 key/value 的設置一樣重要，甚至更加重要。如果容忍效果不匹配。也會導致 Pod 調度不能到對應節點上。
1.4.4 如果 Pod 沒有設置任何的污點容忍,Pod 就不能調度到有污點的節點上。（錯）
如果節點的污點效果是: PreferNoSchedule, 沒有設置任何污點容忍的 Pod 也能調度到此節點上。原因在于:PreferNoSchedule 的意思是優先不調度, 但是當沒有節點可用時,Pod 仍然能調度到此節點。
二
Node Affinity
Node Affinity 可以讓指定應用調度到指定的節點, 這有利于應用的穩定性, 減少重要業務和不重要業務之間相互搶占資源的可能, 同時也可以降低不重要業務對重要業務的影響, 另一方面, 也能夠進行多租戶之間的隔離。根據租戶需求為租戶提供特定的運行環境。
2.1 NodeAffinity 配置要點
NodeAffinity 配置分類兩大部分:
requiredDuringSchedulingIgnoredDuringExecution (強親和性)
preferredDuringSchedulingIgnoredDuringExecution (首選親和性)
但是, 在真實的配置環節時, 又會犯迷糊:
強親和性到底多強算強?
首選親和性中的首選體現在那些方面?
強親和性配置時, 有兩種配置方式, 兩種的區別是什么?
首選親和性中的權重值到底是什么規則? 值越大權重值越高么？還是值越小越高(1 最大)?
首選親和性配置中, 如果 Pod 能匹配 A 節點的多個 Label, 也能匹配 B 節點的一個 Label(A 的 Label 權重之和等于 B 單個 Label 的權重), 這時 Pod 會優先調度到 A 節點么?
縮容時, 是先從低權重的節點上開始殺么？這些問題, 我們都不能全靠注釋和理解去揣測答案, 必須經過實測得到真實答案, 否則一旦上了生產再想修改就需要付出更大的成本。
如果 Pod 是以強親和性的方式綁定在節點上且 Pod 已經正常運行在此節點上, 此時刪除節點的標簽是否會導致 Pod 重啟發生漂移。
強親和性：
requiredDuringSchedulingIgnoredDuringExecution
例子 Node Labels 設定：
level: important(重要)，general(一般),unimportant(不重要)
Pod 與運算的配置:
注意: 強親和性的配置分為: 與運算、或運算兩部分
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: level
operator: In
values:
- important
- key: app
operator: In
values:
- 1
在與運算的配置中, 我們發現, 在同一個 matchExpressions 中既需要匹配 level=important 的標簽也需要匹配 app= 1 的標簽。也就是說:Pod 只會選擇同時匹配這兩個 Label 的節點。
根據上面 Pod 的 Node 親和性設置, 兩個 Label 求一個交集, 只有同時滿足兩個 Label 的節點才會納入這個 Pod 的調度池, 顯而易見, 只有 10.x.x.80 這個節點。所以, 此 Pod 只能調度到這個節點, 如果這個節點資源不足, 那么此 Pod 調度失敗。
Pod 或運算配置：
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: level
operator: In
values:
- important
- matchExpressions:
- key: level
operator: In
values:
- unimportant在或運算的配置中, 我們發現有一個 matchExpressions 數組, 里面的 Label 列表求并集。也就是說:Pod 可以選擇只要匹配其中一個 Label 的節點就行, 不用全匹配。
舉個例子:
節點的 Label 設置沿用上一個例子的。節點的標簽只要能滿足 Pod 的其中一個標簽, 節點就能納入這個 Pod 的調度池, 顯而易見, 這個 Pod 可選的節點有:10.x.x.78, 10.x.x.79,10.x.x.80, 10.x.x.86, 10.x.x.87, 10.x.x.88。
首選親和性:
preferredDuringSchedulingIgnoredDuringExecution
它的使用風格應該是: 如果 Pod 能調度到指定 Label 的節點最好, 如果不能, 也不強求,Pod 選擇其他的節點也行, 即使這個節點根本沒有 Label 或者節點的 Label 和我完全不匹配。
Pod 首選親和性設置:
preferredDuringSchedulingIgnoredDuringExecution:
- preference:
matchExpressions:
- key: level
operator: In
values:
- important
weight: 5
- preference:
matchExpressions:
- key: app
operator: In
values:
- 1
weight: 4
- preference:
matchExpressions:
- key: master
operator: In
values:
- 1
weight: 10示例: Node 的 Label 設置沿用上一個例子的, 根據上面的配置, 我們會看到:
如表所示, 最終 Pod 優先調度到 10.x.x.85, 原因在于 app= 1 的權重是 4, level=important 的權重是 5, 所以: 節點 10.x.x.80 的權重是:9, 但是仍然小于節點:10.x.x.85 的權重。
2.2 問題總結
其實強親和性和首選親和性區別體現在:Pod 對節點的選擇上。就強親和性而言, 如果節點不能匹配 Pod 對 Label 的要求, Pod 永遠不會調度到這類節點上, 即使是 Pod 調度失敗(沒錯, 就是頭鐵), 就首選親和性來說, 能調度到最優節點是一件非常值得開心的事情, 如果不能調度到最優節點可以退而求其次, 總有適合自己的。(回答問題 1)
首選親和性體現在 PodLabel 的權重值上, 而與節點 Label 的匹配個數無關。(回答問題 2)
在首選親和性配置中會多一個權重值的字段(weight), 這個值越大, 權重越大,Pod 調度到對應此 Label 的節點的概率越高。(回答問題 4)
一個節點有多個 Label 且節點能滿足 Pod 所要求的所有 Label, 如果多個 Label 的權重值相加仍然小于某單個 Label 的節點, 那么 Pod 首選是權重值高的節點; 如果 Pod 能匹配到 A 節點的所有 Label, 同時也能匹配到 B 節點某一個 Label. 但是,A 節點 Label 的權重之和剛好等于 B 節點的單個 Label 的權重，這時,Pod 優先選擇的 A 還是 B 這是隨機的(只針對親和性來說是隨機的, 實際情況還要考慮其他情況)。而不會管 Label 的匹配個數。(回答問題 5)
創建或擴容 Pod 時, 優先選擇 Label 匹配權重值大的節點, 若此節點的其他條件不滿足(比如內存不足), 選擇次權重的, 最后選擇 Label 不匹配或者根本沒有 Label 的節點。
(回答問題 6)縮容時, 隨機選擇 Pod 殺掉, 而不是我們預想的從低權重的節點開始殺, 這點值得注意。
(回答問題 7)答案是不會, 正在運行的 Pod 不會被調度到新的節點去, 當 Pod 因為某種原因重啟 (指 Pod 名字改變, 觸發重調度, 名字不改變, 意味著不觸發調度器調度, 只是原地重啟) 后, 會自動調度到符合親和性選擇的節點上。
三
污點和 Node Affinity 的使用總結
就污點而言, 它的使用通常是負向的, 也就說, 污點常用在某 Node 不讓大多數 Pod 調度只讓少部分 Pod 調度時, 又或者節點根本不參加工作負載時。比如: 我們常見的 master 節點上不調度負載 pod, 保證 master 組件的穩定性；節點有特殊資源，大部分應用不需要而少部分應用需要, 如 GPU。
就 Node Affinity 來說, 他的使用可以正向的, 也就是說, 我們想讓某個應用的 Pod 部署在指定的一堆節點上。當然, 也可以是負向的, 比如說我們常說的 Node 反親和性, 只需要把操作符設置為 NotIn 就能達成預期目標。
就污點而言，如果節點設置的污點效果是 NoSchedule 或者 NoExecute, 意味著沒有設置污點容忍的 Pod 絕不可能調度到這些節點上。
就 Node Affinity 而言, 如果節點設置了 Label, 但是 Pod 沒有任何的 Node Affinity 設置, 那么 Pod 是可以調度到這些節點上的。
看完上述內容，你們掌握 Kubernetes 高級調度中如何進行 Taint 和 Toleration、Node Affinity 分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！
