kubernetes 中的搶占功能是調(diào)度器比較重要的feature，但是真正使用起來還是比較危險，否則很容易把低優(yōu)先級的pod給無辜kill。為了提高GPU集群的資源利用率，決定勇于嘗試一番該featrue。當然使用之前還是得閱讀一下相關(guān)的代碼做到心里有數(shù)，出了問題也方便定位修復(fù)。

基本原理

優(yōu)先級與搶占是為了確保一個高優(yōu)先級的pod在調(diào)度失敗后，可以通過"擠走" 低優(yōu)先級的pod，騰出空間后保證它可以調(diào)度成功。 我們首先需要在集群中聲明PriorityClass來定義優(yōu)先等級數(shù)值和搶占策略，

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high
value: 10000
preemptionPolicy: Never
globalDefault: false
description: "This priority class should be used for high priority service pods."
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: low
value: -999
globalDefault: false
description: "This priority class should be used for log priority service pods."

如上所示定義了兩個PriorityClass對象。然后就可以在pod中聲明使用它了：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: nginx
  name: high-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx
        resources:
          limits:
            cpu: "500m"
      priorityClassName: high

這個 Pod 通過 priorityClassName 字段。聲明了要使用名叫 high-priority 的 PriorityClass。當這個 Pod 被提交給 Kubernetes 之后，Kubernetes 的 Priority AdmissionController 就會自動將這個 Pod 的spec.priority 字段設(shè)置為10000。
如下：

  preemptionPolicy: Never
  priority: 10000
  priorityClassName: high

Pod創(chuàng)建好之后，調(diào)度器就會根據(jù)創(chuàng)建的priority進行調(diào)度的決策，首先會在等待隊列中優(yōu)先調(diào)度，如果調(diào)度失敗就會進行搶占： 依次遍歷所有的node找出最適合的node，將該nodename填充在spec.nominatedNodeName字段上，然后等待被搶占的pod全都退出后再次嘗試調(diào)度到該node之上。具體的邏輯請自行閱讀相關(guān)代碼，此處不在贅述。

生產(chǎn)環(huán)境使用方式

• v1.14版本的kubernetes該feature已經(jīng)GA，默認開啟，但此時我們往往沒有做好準備，如果直接給pod設(shè)置優(yōu)先級會導(dǎo)致很多意料之外的搶占，造成故障。 （參見How a Production Outage Was Caused Using Kubernetes Pod Priorities）。所以建議在初次使用的時候還是先顯式關(guān)閉搶占，只設(shè)置優(yōu)先級，等集群中所有的pod都有了各自的優(yōu)先級之后再開啟，此時所有的搶占都是可預(yù)期的。可以通過kube-scheduler 配置文件中的disablePreemption: true進行關(guān)閉
• 調(diào)度器是根據(jù)優(yōu)先級pod.spec.priority數(shù)值來決定優(yōu)先級的，而用戶是通過指定pod.sepc.priorityclass的名字來為pod選擇優(yōu)先級的，此時就需要Priority AdmissionController根據(jù)priorityclass name為pod自動轉(zhuǎn)換并設(shè)置對應(yīng)的priority數(shù)值。我們需要確保該admissionController開啟，如果你的kube-apiserver中還是通過--admission-control flag來指定admissionoController的話需要手動添加Priority admissonController，如果是通過--enable-admission-plugins來指定的話，無需操作，該admissionController默認開啟。
• 按照集群規(guī)劃創(chuàng)建對應(yīng)的PriorityClass及其對應(yīng)的搶占策略，目前支持兩種策略： Never, PreemptLowerPriority。 Never可以指定不搶占其他pod, 即使該pod優(yōu)先級特別高，這對于一些離線任務(wù)較為友好。 非搶占調(diào)度在v1.15中為alpha, 需要通過--feature-gates=NonPreemptingPriority=true 進行開啟。
• 在創(chuàng)建好了PriorityClass之后，需要防止高優(yōu)先級的pod過分占用太多資源，使用resourceQuota機制來限制其使用量，避免低優(yōu)先級的pod總是被高優(yōu)先級的pod壓制，造成資源饑餓。resoueceQuote可以通過指定scope為PriorityClass來限定某個優(yōu)先級能使用的資源量：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: high-priority
spec:
  hard:
    pods: "10"
  scopeSelector:
    matchExpressions:
    - operator : In
      scopeName: PriorityClass
      values: ["high"]

如上即為限制高優(yōu)先級的pod最多能創(chuàng)建10個。operator指定了作用的對象，operator: In可以顯式指定作用于的哪些priorityClass，operator: Exists則指定作用于該namespace下的所有priorityClass。

• 有時候我們想要只有priorityClass對應(yīng)的resourceQuota存在之后才能創(chuàng)建pod，確保所有的priorityClass的pod資源都是受控的。 如果那個namespacew沒有該resourceQuota則拒絕該pod的創(chuàng)建，該操作可以通過指定--admission-control-config-file文件來設(shè)置，內(nèi)容如下:

apiVersion: apiserver.k8s.io/v1alpha1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
  configuration:
    apiVersion: resourcequota.admission.k8s.io/v1beta1
    kind: Configuration
    limitedResources:
    - resource: pods
      matchScopes:
      - scopeName: PriorityClass 
        operator: In
        values: ["high"]

該配置定義了： "high"優(yōu)先級的pod只能在指定的namespaces下創(chuàng)建，該namespaces有作用于"high"優(yōu)先級的resouceQuota，上面第四步中的resouceQuota即可滿足要求。
scopeName定義了作用的對象為priorityClass, operator指定了作用的范圍，可以是In操作符，指定某幾個value, 也可以是Exits操作符，指定所有的PriorityClass必須有對應(yīng)的quota存在, 否則該namespace就無法創(chuàng)建該優(yōu)先級的pod，這些操作符與上面resouceQuota中定義的一一對應(yīng)。通過這樣就限制了一些優(yōu)先級只能在有資源約束的namespace下創(chuàng)建。

• 如果沒有顯式指定優(yōu)先級，則默認的優(yōu)先級值為0，需要結(jié)合業(yè)務(wù)規(guī)劃決定是否有必要調(diào)整默認優(yōu)先級。
• 對于一些daemonset需要顯式設(shè)置較高的優(yōu)先級來防止被搶占，在部署一個新的daemonset的時候需要考慮是否會造成大規(guī)模pod的搶占。
• 等到所有的優(yōu)先級設(shè)置完畢之后就可以開啟搶占功能了，此時集群中所有pending 的高優(yōu)先級pod就會瞬間搶占，還是需要額外小心，確保集群中高優(yōu)先級的pod不會導(dǎo)致低優(yōu)先級的pod大規(guī)模被kill，如果我們提前設(shè)置了對應(yīng)的resource quota值，則會有一定的資源約束。
• 優(yōu)先級和搶占對于資源的精細化運營考驗很大，對于resource quota的設(shè)置需要十分精細，需要考慮兩個維度來設(shè)置： namespace層面和priority層面，我們既希望限制namespace使用的資源，有希望某個priority使用的資源，防止低優(yōu)先級的pod資源饑餓。 可以在初期只考慮namespace層面的限制，priority層面通過上層業(yè)務(wù)來保證，例如創(chuàng)建任務(wù)的時候保證集群中高優(yōu)先級的資源使用量不超過50%等。

其他思考

筆者的線上環(huán)境中， 有些再跑的模型訓練任務(wù)業(yè)務(wù)對于自動failove實現(xiàn)不是很好，如果中途被搶占了只能從頭開始計算，需要占用額外的GPU資源，這種工作類型不允許被搶占，但是如果把他設(shè)置為高優(yōu)先級又不太合適，因為它確實不是最高的優(yōu)先級，優(yōu)先級最高的還是在線業(yè)務(wù)，不能讓它搶占在線業(yè)務(wù)。 它屬于中間優(yōu)先級，可以搶占低優(yōu)先級的pod。 經(jīng)過探索發(fā)現(xiàn)目前kubernetes并不支持該中類型，當前支持的搶占策略為： Never, PreemptLowerPriority都無法滿足需求。所以在此基礎(chǔ)上開發(fā)了NonPreemptible類型的搶占策略，該優(yōu)先級的pod是不允許被其他人搶占的，調(diào)度還是按照優(yōu)先級在隊列里排隊，但是一旦調(diào)度上去就無法被搶占。
這種搶占策略略顯"霸道"，所以需要謹慎使用，設(shè)置resouceQuota，并且只能由特定的任務(wù)使用。 并且為了不影響deamonset等優(yōu)先級最高的任務(wù)，允許被某個指定Priority數(shù)值之上的pod搶占。并且隨著業(yè)務(wù)的發(fā)展，這部分邏輯需要逐步去掉，之所有存在這部分邏輯是因為pod不能被中斷，不能被搶占，所以還是需要使這些任務(wù)支持重啟與掛起，具體來說就是： pod掛載遠程磁盤并自動checkpoint，重啟之后從以前的恢復(fù)點繼續(xù)執(zhí)行。等這些業(yè)務(wù)改造完成之后，逐步去掉這種工作搶占策略

reference

Pod Priority and Preemption
Priority in ResourceQuota
Allow PriorityClasses To Be Non-Preempting