(避免Pod和Node同時出現在一小段文字中,所以Node以節點漢字表述)

污點的理論支撐

使用效果(Effect):

• PreferNoSchedule:調度器盡量避免把Pod調度到具有該污點效果的節點上,如果不能避免(如其他節點資源不足),Pod也能調度到這個污點節點上。

• NoSchedule:不容忍該污點效果的Pod永不會被調度到該節點上，通過kubelet管理的Pod(static Pod)不受限制;之前沒有設置污點的Pod如果已運行在此節點(有污點的節點)上，可以繼續運行。

• NoExecute: 調度器不會把Pod調度到具有該污點效果的節點上，同時會將節點上已存在的Pod驅逐出去。

污點設置的第一前提是: 節點上的污點key和Pod上的污點容忍key相匹配。

當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需要容忍此節點的所有污點。

• 在污點容忍設置時,若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決策的結果，這是兩個組件分管不同工作產生的效果,下面這種配置除外。

1.4.1當一個節點設置了污點，那么只要設置Pod對此污點容忍就能調度上去且能正常運行。（錯）

當節點的一個污點的影響效果被設置為:NoExecute,此時Pod對此污點的容忍效果也是NoExecute時, Pod能調度上去，但是也會被Terminating，不斷的處于Terminating,ContainerCreating的過程。

對Node設置污點：

Pod設置的污點容忍：

效果：

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可以讓指定應用調度到指定的節點,這有利于應用的穩定性,減少重要業務和不重要業務之間相互搶占資源的可能,同時也可以降低不重要業務對重要業務的影響,另一方面,也能夠進行多租戶之間的隔離。根據租戶需求為租戶提供特定的運行環境。

NodeAffinity配置分類兩大部分:

requiredDuringSchedulingIgnoredDuringExecution (強親和性)

preferredDuringSchedulingIgnoredDuringExecution (首選親和性)

但是,在真實的配置環節時,又會犯迷糊:

• 強親和性到底多強算強?

• 首選親和性中的首選體現在那些方面?

• 強親和性配置時,有兩種配置方式,兩種的區別是什么?

• 首選親和性中的權重值到底是什么規則? 值越大權重值越高么？還是值越小越高(1最大)?

• 首選親和性配置中, 如果Pod能匹配A節點的多個Label,也能匹配B節點的一個Label(A的Label權重之和等于B單個Label的權重),這時Pod會優先調度到A節點么?

• 縮容時,是先從低權重的節點上開始殺么？ 這些問題, 我們都不能全靠注釋和理解去揣測答案,必須經過實測得到真實答案,否則一旦上了生產再想修改就需要付出更大的成本。

• 如果Pod是以強親和性的方式綁定在節點上且Pod已經正常運行在此節點上,此時刪除節點的標簽是否會導致Pod重啟發生漂移。

強親和性：

requiredDuringSchedulingIgnoredDuringExecution

例子Node Labels設定：

Pod與運算的配置:

注意: 強親和性的配置分為: 與運算、或運算兩部分

在與運算的配置中,我們發現,在同一個matchExpressions中既需要匹配level=important的標簽也需要匹配app=1的標簽。也就是說:Pod只會選擇同時匹配這兩個Label的節點。

根據上面Pod的Node親和性設置,兩個Label求一個交集,只有同時滿足兩個Label的節點才會納入這個Pod的調度池,顯而易見,只有10.x.x.80這個節點。所以,此Pod只能調度到這個節點,如果這個節點資源不足,那么此Pod調度失敗。

Pod或運算配置：

在或運算的配置中,我們發現有一個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首選親和性設置:

示例: Node的Label設置沿用上一個例子的, 根據上面的配置,我們會看到:

如表所示, 最終Pod優先調度到10.x.x.85, 原因在于app=1的權重是4, level=important的權重是5, 所以:節點 10.x.x.80的權重是:9,但是仍然小于節點:10.x.x.85的權重。

1. 其實強親和性和首選親和性區別體現在:Pod對節點的選擇上。就強親和性而言,如果節點不能匹配Pod對Label的要求, Pod永遠不會調度到這類節點上,即使是Pod調度失敗(沒錯,就是頭鐵),就首選親和性來說,能調度到最優節點是一件非常值得開心的事情,如果不能調度到最優節點可以退而求其次,總有適合自己的。 (回答問題1)

2. 首選親和性體現在PodLabel的權重值上,而與節點Label的匹配個數無關。(回答問題2)

3. 在首選親和性配置中會多一個權重值的字段(weight),這個值越大,權重越大,Pod調度到對應此Label的節點的概率越高。(回答問題4)

4. 一個節點有多個Label且節點能滿足Pod所要求的所有Label,如果多個Label的權重值相加仍然小于某單個Label的節點,那么Pod首選是權重值高的節點;如果Pod能匹配到A 節點的所有Label,同時也能匹配到B 節點某一個Label.但是,A節點 Label的權重之和剛好等于B 節點的單個Label的權重，這時,Pod優先選擇的A還是B這是隨機的(只針對親和性來說是隨機的,實際情況還要考慮其他情況)。而不會管Label的匹配個數。(回答問題5)

5. 創建或擴容Pod時,優先選擇Label匹配權重值大的節點,若此節點的其他條件不滿足(比如內存不足),選擇次權重的,最后選擇Label不匹配或者根本沒有Label的節點。

6. (回答問題6)縮容時,隨機選擇Pod殺掉,而不是我們預想的從低權重的節點開始殺,這點值得注意。

7. (回答問題7)答案是不會,正在運行的Pod不會被調度到新的節點去, 當Pod因為某種原因重啟(指Pod名字改變,觸發重調度,名字不改變,意味著不觸發調度器調度,只是原地重啟)后,會自動調度到符合親和性選擇的節點上。

1. 就污點而言,它的使用通常是負向的, 也就說, 污點常用在某Node不讓大多數Pod調度只讓少部分Pod調度時,又或者節點根本不參加工作負載時。比如:我們常見的master節點上不調度負載pod,保證master組件的穩定性；節點有特殊資源，大部分應用不需要而少部分應用需要,如GPU。

2. 就Node Affinity來說,他的使用可以正向的,也就是說,我們想讓某個應用的Pod部署在指定的一堆節點上。當然,也可以是負向的,比如說我們常說的Node 反親和性,只需要把操作符設置為NotIn就能達成預期目標。

3. 就污點而言，如果節點設置的污點效果是NoSchedule或者NoExecute,意味著沒有設置污點容忍的Pod絕不可能調度到這些節點上。

4. 就Node Affinity而言,如果節點設置了Label,但是Pod沒有任何的Node Affinity設置,那么Pod是可以調度到這些節點上的。