Pod可以擁有優先級.優先意味着相對於其它pod某個pod更為重要.如果重要的pod不能被調度,則kubernetes調度器會優先於(驅離)低優先級的pod來讓處於pending狀態的高優先級pod被調度.
kubernetes 1.9以后,優先級會影響pod的調度順序和資源耗盡時pod的驅離順序
警告:在一個不是所有用戶都被信任的集群里,可能有惡意用戶創建最高可能優先級的pod,導致其它pod被驅離或者無法調度.為了解決這個問題,需要增大資源配額來支持優先pod.集群管理員可以為特定用戶創建特定優先級級別,防止他們創建高優先級的pod.這項功能在1.12版本里為beta狀態.
怎樣使用優先級和搶占
在1.11或以后的版本里,按下面指示來操作:
-
創建一個或者多個
PriorityClasses -
創建一個pod,並把
priorityClassName設置為以上添加的priorityClassName中的一個.當然你不必直接創建pod,你可以把priorityClassName添加到集合對象(比如deployment)的template里.
如果你僅想嘗試這項功能並且然后把它禁用,你必須把PodPriority設置為false,然后重啟apiserver和調度器.被禁用以后,已經存在的pod仍然保留有它們的優先級字段,但是搶占不會再生效,並且優先字段被忽略.你也不能再向新的pod添加priorityClassName字段
怎樣禁用搶占
在kubernetes 1.12+ 當集群處於較大資源壓力時,一些關鍵的pod依賴搶占調度.因此強烈為建議禁用搶占
在kubernetes1.11以后版本,搶占被kube-scheduler的的disablePreemption標識控制,默認設置是false.如果你不顧建議仍然想要禁用它,可以把它設置為true
這個選項僅僅在組件的配置里有效,在舊式的命令行下無效.下面是一個配置的示例:
apiVersion: componentconfig/v1alpha1
kind: KubeSchedulerConfiguration
algorithmSource:
provider: DefaultProvider
...
disablePreemption: true
搶占
當pod被創建,他們進入隊列等待被調度.調度器從隊列取出一個pod並且嘗試把它調度到一個節點上.如果沒有節點能夠滿足這個pod的所有要求,搶占邏輯被觸發,我們把這個掛起的pod稱作P.調度器嘗試尋找移除一個或者多個比P低的pod后能夠使得P被調度的節點.如果找到了一個這樣的節點,一個或者多個優先級低的節點被驅離,然后P被調度到這個節點上.
當pod P搶占了Node N上的一個或者多個pod的資源,P的nominatedNodeName(候選節點)字段被設置為節點N的名字.這個字段幫助調度器追蹤為P預留的資源信息,並給用戶提供集群資源搶占的一些信息.
需要注意的是pod P並不總是調度到候選節點(nominated Node)上,當受害的pod被搶占,他們進入終止階段.當受害pod停止的過程中其它節點變得可用,這時候調度器就會使用這個可用的節點來接收pod P,這樣就造成nominatedNodeName和nodeName並不總是相同.並且,pod P搶占了節點N上的優先級低的pod的資源時,這時候有更高優先級的pod到達,這時候調度器可能會把節點N讓給這個更高優先級的pod使用.這時候調度器會清除pod P的nominatedNodeName字段,這樣,調度器使用pod P可以搶占其它節點上的資源.
搶占限制
受害pod的優雅終止
當被搶占,受害pod進入優雅終止期,它們將有時間完成工作並退出.否則,會被殺掉.這個優雅終止期在調度器搶占受害pod資源和優先pod被調度到Node N之間創建了一個時間間隔.同時,調度器繼續調度其它狀態為pending的pod.為了縮短這個時間間隔,用戶可以把優雅終止期設置為0或者一個很小的時間
低優先級pod的pod間親和性
問題:如果所有低優先級的pod都從一個節點上移除了,那么掛起(pending)的pod是否可以調度到此節點上?
這個問題的意義在於如果所有的pod都被移除,資源仍然不夠容納掛起的pod會怎么樣?
僅當以上問題的答案是肯定的(yes)的時候,節點的搶占才會發生(也就是如果全部低優先級的pod都被驅離仍然不夠容納新的pod時,節點上不會發生搶占)
需要注意的是,並不是總是要移除節點上的所有低優先級的pod.如果僅僅移除一些pod就足以容納掛起的pod時,僅有部分低優先級的pod被移除.但是以上問題的答案仍然需要是肯定的(也就是說低優先級pod的移除建立在移除后資源足以容納新的掛起的節點的基礎上的)
如果掛起的pod(即將被調度的)和一個或者多個節點N上的低優先級的pod有pod間親和關系,如果低優先級pod離開后pod間的親和關系不能被滿足時,調度器這時候不會再搶占節點N上的pod.調度器可能會找到一個其它的合適的節點,也可能找不到.這就無法保證掛起的pod被調度.
對於這個問題我們的建議是創建pod間親和關系時,只向同等優先級和更高優先級的pod創建.
跨節點搶占
假設Node N 上准備搶占以便是pod P可以被調度到N上,但是P依賴於其它節點上的pod被驅離才可以被調度到N上,以下示例說明這個問題
-
Pod P准備調度到節點N上
-
pod Q們於和節點N同一區域的其它節點上
-
pod P和pod Q有區域級別的反親和關系(topologyKey:
failure-domain.beta.kubernetes.io/zone) -
pod P和同一區域內的其它pod沒有反親和關系
-
為了把pod P調度到節點N上,Pod Q可以被搶占,但是調度器不會執行跨節點搶占,因此pod P不會被調度到節點N上.
-
如果pod Q從它的節點上移除,這時候違反親和關系也消失,此時pod P可能會被調度到節點N上
-
在未來的版本中如果能找到一個能保證性能的算法,我們可能會考慮增加跨節點驅離.但是目前我們什么都不能保證.
調度pod優先級和搶占
pod優先級和資源搶占的編排如果有bug的話則往往是導致節點調度中斷的主要原因之一
pod優先級和資源搶占可能導致的問題
以下是如果pod優先級和資源搶占包含bug可能導致的問題的不完全羅列:
- pod被非必要地搶占
當集群出現資源壓力時,調度器會移除優先級低的pod來為優先級高的pod騰出資源,如果用戶錯誤地給分配給一些pod過高的優先權,這些無意分配的高優先權會導致集群搶占.像上面提到的,pod的優先權通過設置podSpec字段的priorityClassName來實現的,優先級的整數字段然被解析后傳入到podSpec字段的priority字段里
為了解決這個問題,priorityClassName字段必須改變到更小的優先級或者留空,priorityClassName字段留空會被解析為0
當一個pod被搶占,則它會產生一條event記錄來記錄這個事件.僅當集群沒有足夠的資源時搶占才會發生.這種情況僅發生在(掛起)的pod的優先級高於受害pod.如果沒有掛起的pod,則搶占事件一定不能發生.如果沒有掛起pod,或者掛起pod的優先級等於或小於受害pod時發生搶占事件,則是系統bug,請提交一個issue給我們.
pod被搶占,但是搶占的pod並沒有被調度
當pod被搶占,他們將接收到一個優雅停止的時間段,默認是30秒,但是也可以是任意在podSpec里指定的值.如果受害pod沒有在指定的時段里停止,他們會被強行終止.當所有受害者都被移除,優先pod可以被調度.
當優先pod等待受害者被移除時,一個適合調度到這個節點上的更高優先級的pod被創建.這時候調度器會優先調度這個更高優先級的pod
高優先級的pod比優先級更低的pod被搶占
調度器會盡力尋找適合的節點來調度掛起的pod,如果找不一節點來調度,調度器會從一個包含低優先級的節點上移除pod來為掛起的pod騰出空間.如果有低優先級pod的節點不適合被調度,調度器可能會選擇一個更高優先級的節點來搶占(這里說的更高是相對前面找到的低優先級的pod而言的,而不是對優先pod而言的).被搶占的pod仍然必須要比優先pod(指掛起的需要調度的pod)優先級別低
當有多個節點可以被搶占時,調度器會嘗試選擇有最低優先級pod的節點來調度.但是如果pod有PodDisruptionBudget並且搶占可能會違反PodDisruptionBudget時,調度器可能會選擇一個更高優先級的pod來搶占.
當有多個節點可以被搶占並且沒有出現以上情形,則調度器會選擇優先級最低的pod來搶占,如果不是這樣的,則意味着調度器本身存在bug.
pod優先級和Qos交互
pod優先級和QoS是兩個正交的功能,幾乎沒有交叉.調度器的搶占邏輯當選擇搶占對象時不會考慮QoS.搶占會考慮pod的優先級並選擇出一系列低優先級搶占目標.只有當即便移除低優先級pod也不足以運行掛起的pod或者低優先級的pod被PodDisruptionBudget保護時,調度器才會選擇更高優先級的pod作為搶占對象.
僅有Kubelet的 out-of-resource eviction組件才會同時考慮pod優先級和QoS,kubelet首先會根據使用的資源是否超過請求的值來對要驅離的pod進行排序,然后根據優先級.Kubelet out-of-resource eviction 不會驅離使用資源低於請求資源的pod,如果一個低優先級的pod使用的資源沒有超過它請求的,則它不會被驅離.其它的使用資源超過其申請資源的更高優先級的pod可能會被驅離.