Kubernetes CKA課程筆記 62

Scheduling Pods — Inter-Pod Affinity(針對Dynamic infrastructure的Rule設置)理論

考量到動態機台配置(Dynamic infrastructure)

根據工作量(workload)增加或減少機台配置:

依據工作量增減的機台數量

此時有設計一個一個叫log-coll的Pod

專門指定佈署在master node上(nodeSelector指定master)

並且是透過Deployment元件定義replicas的數量5

用來應付workload高峰時,最大可能master node數量5的狀況

但是平常工作流量可能沒那麼高,只會運行一台master node

這將會造成我們定義的5個將全部會佈署到這剩餘的一台master node上

可能運行上沒問題,但是資源就浪費了,最好當然還是一台master只佈署一個

並且之後master node增加了

原本在單台master上運行好好的5個Pod也不會重新長到新機台上了

要解決上述這種狀況而延伸的規則就是 →Inter-Pod Anti-Affinity (Rule)

Inter-Pod Anti-Affinity (Rule):

• 讓Pod透過Label只被Schedul到指定某些Node,並且這些Node上尚未有特定Pod在上面
• 由上面replicas=5的例子就是只會建出一個Pod,剩餘四個不會在長在同一台master node上
• 這就是Anti-Affinity(Rule)

當然也有另一個反向的設置 →Inter-Pod Affinity (Rule)

Inter-Pod Affinity (Rule):

• 考量到如下的master node有的etcd配置:

• 在不是每台都有etcd的master node配置下
• 當有Pod只想佈署到etcd的node上時
• 透過Inter-Pod Affinity (Rule)就可以實現如下:

my-app只佈署到有etcd的master node上

• 在上述狀況下,若my-app的replicas=3
• 只要再加上剛剛所說的Anti-Affinity(Rule)
• 就能阻止第三個my-app被佈署上去

實際模擬撰寫Inter-Pod Affinity/Anti-Affinity (Rule)的Configuration File

由於畢竟我們的機台配置也就只有一台master node

所以下面僅嘗試建立撰寫deployment Configuration File:

延續前幾篇學的加入nodeSelector(詳59篇筆記)與tolerations(詳61篇筆記)

但是這次是在deployment元件裡面的Pod區塊設置,初期設置如下:

並且也跟上面例子一樣,假設要起Pod到有etcd的master node上

所以要設置Inter-Pod Affinity (Rule)

並且怕replicas=5情況下,總共五個Pod都重複地長在同一個master

所以要設置Inter-Pod Anti-Affinity (Rule)

這些設置都屬於affinity區塊,所以其實類似NodeAffinity(詳60篇筆記)

實際如下圖示:

有空可以放大仔細理解,一個是要(podAffinity),一個不要(podAntiAffinity)

另外要注意到的是topologyKey:

hostname層級就是比較常見的設定,其他層級的只能看看官網怎麼設

比較Node Affinity與Inter-Pod Affinity:

• Node Affinity:作用於Node Labels
• Inter-Pod Affinity(或Anti-Affinity):作用於Pod Labels

並且其實這整個概念跟最前面講述元件的課程中提到的 — DaemonSet很像

DaemonSet僅replicas到每個worker各一個

講師最後強調:

Scheduling Pods從筆記59到本篇62的設置盡量不要太常使用

因為K8s本身已經有自己定義的自動Scheduling,ReScheduling機制

我們若建立過多的Scheduling Pods限制(constraint)

可能會妨礙到K8s本身的Scheduling機制

所以這類Scheduling Pods限制(constraint)最好以最小限度的使用!

參考課程(reference)