Kubernetes scheduler學(xué)習(xí)筆記是怎樣的，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。

富民ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：13518219792（備注：SSL證書合作）期待與您的合作！

簡介

Kubernetes是一個(gè)強(qiáng)大的編排工具，可以用來很方便的管理許多臺(tái)機(jī)器，為了使機(jī)器的資源利用率提高，同時(shí)也盡可能的把壓力分?jǐn)偟礁鱾€(gè)機(jī)器上，這個(gè)職責(zé)就是由scheduler來完成的。

Kubernetes scheduler是一個(gè)策略豐富、拓?fù)涓兄?、工作?fù)載特定的功能，顯著影響可用性、性能和容量。

為了能更好的使用它，所以從源碼的角度，對(duì)它進(jìn)行一個(gè)全方位的分析與學(xué)習(xí)。

scheduler的功能不多，但邏輯比較復(fù)雜，里面有很多考慮的因素，總結(jié)下來大致有如下幾點(diǎn)：

• Leader選主，確保集群中只有一個(gè)scheduler在工作，其它只是高可用備份實(shí)例。通過endpoint:kube-scheduler作為仲裁資源。

• Node篩選，根據(jù)設(shè)置的條件、資源要求等，匹配出所有滿足分配的Node結(jié)點(diǎn)。

• 最優(yōu)Node選擇。在所有滿足條件的Node中，根據(jù)定義好的規(guī)則來打分，取分?jǐn)?shù)最高的。如果有相同分?jǐn)?shù)的，則采用輪詢方式。

• 為了響應(yīng)高優(yōu)先級(jí)的資源分配，增加了搶占功能。scheduler有權(quán)刪除一些低優(yōu)先級(jí)的Pod，以釋放資源給高優(yōu)先級(jí)的Pod來使用。

功能說明

代碼看下來比較困難，下面將分幾個(gè)場景來描述scheduler工作的過程：

1、環(huán)境說明（假設(shè)3臺(tái)機(jī)器，分別是8C16G）

場景一：資源分配——最基本的功能

2、先分配一個(gè)請(qǐng)求2C4G的Pod：A

場景二：機(jī)器負(fù)載均衡——評(píng)分機(jī)制

3、再分配一個(gè)請(qǐng)求2C4G的Pod：B（盡管node1上還有空閑資源可分配B，但node2和node3空閑資源更多，打分更高，所以分配到了node2<選擇node2還是node3，是由schedule輪詢選擇的>。）

4、同理，如果再分配一個(gè)C，scheduler會(huì)優(yōu)先分配到node3上

場景三：資源搶占——特權(quán)機(jī)制

5、現(xiàn)在3個(gè)Node上都分配了2C4G，就是都剩余6C12G，如果我這個(gè)時(shí)候分配一個(gè)8C12G的Pod：D，在同優(yōu)先級(jí)的情況下，D將不會(huì)分配，處于Pending狀態(tài)，因?yàn)槿_(tái)機(jī)器都資源不足。

6、如果這個(gè)時(shí)候，我給D設(shè)置一個(gè)高的優(yōu)先級(jí)，schedule會(huì)刪除一臺(tái)機(jī)器上的Pod，比如A，然后資源足夠了，將D分配到node1上，再將A分配到node2或node3上。（這里分配是一個(gè)類似，因?yàn)槿_(tái)都是一樣的）

7、下面實(shí)戰(zhàn)一把，詳細(xì)試驗(yàn)下scheduler的搶占過程：

我有一個(gè)Deployment，有3個(gè)復(fù)本，分別分配到兩臺(tái)機(jī)器上。（為什么用這個(gè)例子，是為了說明，搶占一定會(huì)發(fā)生在10-10-40-89上，因?yàn)橐獎(jiǎng)h除的Pod最少）

這個(gè)時(shí)候，我創(chuàng)建一個(gè)高優(yōu)先級(jí)的Deployment：

快速查詢，能看到下面的階段：

第一步，將要分配的testpc-745cc7867-fqbp2設(shè)置為“提名Pod”，這個(gè)名字后面會(huì)再出現(xiàn)，同時(shí)刪除原10-10-40-89上的testpod，由于截的比較慢，下圖中新的testpod已經(jīng)在10-10-88-99上創(chuàng)建了。

第二步，提名Pod將會(huì)分配到對(duì)應(yīng)的結(jié)點(diǎn)上（等待Terminating狀態(tài)的Pod釋放完資源后）。

第三步，資源足夠，Pod正常Running。

最后展示下watch情況下的事件：

測試我共有兩個(gè)yaml文件，如下：

testpod.yaml：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  labels:
    k8s-app: testpod
  name: testpod
spec:
  progressDeadlineSeconds: 600
  replicas: 3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: testpod
  template:
    metadata:
      labels:
        k8s-app: testpod
    spec:
      containers:
      - image: nginx:1.17
        imagePullPolicy: IfNotPresent
        name: nginx
        ports:
        - containerPort: 80
          name: nginx
          protocol: TCP
        resources:
          requests:
            cpu: 1
            memory: 2Gi

testpc.yaml：

apiVersion: scheduling.k8s.io/v1beta1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000000
globalDefault: false
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  labels:
    k8s-app: testpc
  name: testpc
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: testpc
  template:
    metadata:
      labels:
        k8s-app: testpc
    spec:
      containers:
      - image: nginx:1.17
        imagePullPolicy: IfNotPresent
        name: nginx
        ports:
        - containerPort: 80
          name: nginx
          protocol: TCP
        resources:
          requests:
            cpu: 6
            memory: 2Gi
      priorityClassName: high-priority

場景四：關(guān)系戶——親和與反親和

scheduler在分配Pod時(shí)，考慮的要素很多，親和性和反親和，是一個(gè)比較常用的，在這里做一個(gè)典型來講講。

比如在上圖中，我新的Pod：D，要求不能和A在一臺(tái)機(jī)器上，和B的互斥打分是100，和C的互斥打分是10。表示說，D一定不能和A在一臺(tái)機(jī)器，盡可能不和B、C在同一臺(tái)機(jī)器，實(shí)在沒辦法時(shí)（資源不足），D更傾向于和C在一起。

樣例：

podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: security
          operator: In
          values:
          - S2
      topologyKey: kubernetes.io/hostname

通過對(duì)這四個(gè)應(yīng)用場景的分析，對(duì)它的功能有了一個(gè)初步的了解。要想更全面、深入的了解它的功能，需要從它的源碼來著手。下面將從源碼層面來做深入分析。

代碼分析

scheduler總體結(jié)構(gòu)

scheduler的配置，基本都是采用默認(rèn)配置，圖中列出了它的配置加載流程，基本都是加載它自身的默認(rèn)配置。

server.Run為它的主體邏輯，之后會(huì)詳細(xì)講解。

重要配置講解

圖中，單獨(dú)列出了兩個(gè)config配置：

1、disablePreemption：

scheduler有個(gè)搶占功能。當(dāng)Pod調(diào)度發(fā)現(xiàn)無可用資源時(shí)，它會(huì)將比該P(yáng)od優(yōu)先級(jí)低的Pod刪除，以釋放資源給它來調(diào)度。disablePreemption默認(rèn)為false，表示開啟搶占，如果需要關(guān)閉，則設(shè)置為true。

2、既然說到優(yōu)先級(jí)，所以我還列出來了優(yōu)先級(jí)的設(shè)置方法。

Kubernetes中有個(gè)單獨(dú)的優(yōu)先級(jí)的資源，叫：PriorityClass，通過下面這個(gè)yaml，能創(chuàng)建一個(gè)PriorityClass。

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for XYZ service pods only."

然后可將這個(gè)PriorityClass關(guān)聯(lián)到Pod上：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
 priorityClassName: high-priority

這樣就完成的Pod優(yōu)先級(jí)的設(shè)置。如果不設(shè)置，Pod默認(rèn)是同一優(yōu)先級(jí)（為0）。

特別注意：

static Pod比較特殊，需要直接設(shè)置priority，因?yàn)閗ubelet是根據(jù)priority來判斷。

scheduler啟動(dòng)流程

通過深入分析server.Run，可看到如下流程：

server.Run還是有一部分的配置處理流程。

schedulerConfig中，根據(jù)默認(rèn)的參數(shù)，加載了兩大塊內(nèi)容：predicate、priority函數(shù)。

• predicate函數(shù)用于做Pod是否可分配到Node上的檢查函數(shù)。

• priority函數(shù)，則用于選優(yōu)。當(dāng)可分配的Node有多個(gè)時(shí)，這個(gè)時(shí)候就會(huì)根據(jù)priority函數(shù)來給node打分，最終調(diào)度到分?jǐn)?shù)最高的Node上。

Kubernetes提供了這些默認(rèn)的判斷函數(shù)：

predicate：

1、CheckNodeConditionPredicate

we really don’t want to check predicates against unschedulable nodes.

檢查Node狀態(tài)：是否處于可調(diào)度狀態(tài)等。

-----> 遍歷nodeInfo中Node的所有狀況：

• 如果Node類型為ready，并且狀態(tài)不是True，則認(rèn)為結(jié)點(diǎn)為notReady

• 如果Node類型為OutOfDisk，并且狀態(tài)不是False，則認(rèn)為結(jié)點(diǎn)OutOfDisk

• 如果Node類型為NetworkUnavailable，并且狀態(tài)不是False，則認(rèn)為結(jié)點(diǎn)狀態(tài)為：NetworkUnavailable

檢查Node的spec，如果是UnSchedulable，則認(rèn)為結(jié)點(diǎn)為UnSchedulable。

以上檢查都通過，則返回匹配成功。

2、PodFitsHost

we check the pod.spec.nodeName.

檢查pod.spec.nodeName是否匹配。

----> 如果Pod未指定NodeName，則返回匹配成功。

檢查Node的名字，如果與Pod指定的同名，則匹配成功，否則返回：nodeName不匹配。

3、PodFitsHostPorts

we check ports asked on the spec.

檢查服務(wù)端口是否被占用。

-----> 如果元數(shù)據(jù)metadata中有定義需要的podPorts，則直接從元數(shù)據(jù)中取，否則從Pod的所有容器中獲取需要的port。

如果需要的port為空，則返回匹配成功。

從nodeInfo中獲取當(dāng)前已經(jīng)使用的port，如果有沖突，則返回：端口不匹配，否則返回匹配成功。

4、PodMatchNodeSelector

check node label after narrowing search.

檢查label是否匹配。

------> 如果Pod中定義了NodeSelector，則根據(jù)選擇來匹配Node的labels，如果不匹配，則返回NodeSelectorNotMatch。

如果Pod的Affinity中定義了NodeAffinity，則檢查結(jié)點(diǎn)親和關(guān)系：

• 如果未定義requiredDuringSchedulingIgnoredDuringExecution，則直接返回匹配。

• 如果定義了requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms，則里面有一個(gè)匹配，則匹配。否則認(rèn)為不匹配。

特別的：如果nodeSelectorTerms為nil，則全不匹配；如果nodeSelectorTerms不為nil，但是空的切片，則全不匹配；同樣，nodeSelectorTerms中的MatchExpressions，如果為nil或者是空切片，也不匹配。

5、PodFitsResources

this one comes here since it’s not restrictive enough as we do not try to match values but ranges.

-----> 檢查Node的allowedPodNumber是否超過，如果超過，增加超限錯(cuò)誤（此處未直接返回，會(huì)把所有錯(cuò)誤檢查完一次性返回）。

檢查元數(shù)據(jù)中是否有定義podRequest、ignoredExtendedResources，如果定義了，則從元數(shù)據(jù)中取。否則從Pod中每個(gè)容器中取：先檢查所有container中所有需要的資源總合，再檢查initContainer中，如果有資源比總合還大，則取較大的為所需要的資源。

如果需要的資源都為0，則返回檢查結(jié)果。

獲取Node的可用資源，檢查需要新申請(qǐng)的資源+已申請(qǐng)的資源是否超過可用資源，如果超過，則記錄資源不足。

檢查所有Pod擴(kuò)展資源，并判斷擴(kuò)展資源是否需要檢查（ignoredExtendedResources），如果需要檢查，則判斷資源是否足夠，不足夠則記錄失敗。

返回檢查結(jié)果（如果無失敗，是檢查成功）。

6、NoDiskConflict

Following the resource predicate, we check disk.

----> 遍歷Pod所有存儲(chǔ)、Node下的所有Pod，檢查是否有存儲(chǔ)沖突：

如果Pod無存儲(chǔ)（無GCE、AWS、RBD、ISCSI），則檢查通過。

7、PodToleratesNodeTaints

check toleration here, as node might have toleration.

-----> 檢查結(jié)點(diǎn)是否容忍taint環(huán)境：

參數(shù)：Pod中定義的容忍規(guī)則：tolerations，Node中的環(huán)境狀態(tài)：taints，篩選規(guī)則：取effect為NoSchedule、NoExecute的。

如果Node無taints，返回匹配成功。

遍歷所有taints，如果taint不滿足篩選規(guī)則，則跳過檢查。

遍歷所有的容忍規(guī)則，檢查是否有規(guī)則是允許結(jié)點(diǎn)的taint狀態(tài)。檢查步驟：

1. 如果effect為空，則檢查通過，否則要相同。

2. 如果key為空，則檢查通過，否則要相同。

3. 如果operator為Exists，則檢查通過，如果為空或者是Equal，則要相同，否則不通過。

8、PodToleratesNodeNoExecuteTaints

check toleration here, as node might have toleration.

-----> 檢查規(guī)則同上相似，只是篩選規(guī)則變了：取effect為NoExecute的。

9、CheckNodeLabelPresence

labels are easy to check, so this one goes before.

------> 檢查label是否存在，不關(guān)心值。可設(shè)置label存在與不存在。

只有在scheduler.CreateFromConfig(policy)才會(huì)初始化該檢查，在RegisterCustomFitPredicate中注冊，默認(rèn)無該檢查。

10、checkServiceAffinity

-----> 檢查服務(wù)類同關(guān)系。

如果一個(gè)Pod的服務(wù)調(diào)度到有l(wèi)abel:"region=foo"的Node，之后有相同服務(wù)的Pod都會(huì)調(diào)度到該Node。

11、MaxPDVolumeCountPredicate

-----> 檢查掛載的卷個(gè)數(shù)是不是超標(biāo)，只支持：ESB：39，GCE：16，AzureDisk：16。

12、VolumeNodePredicate

-----> 無

13、VolumeZonePredicate

-----> 檢查存儲(chǔ)區(qū)域劃分：

檢查Node中是否有l(wèi)abel：failure-domain.beta.kubernetes.io/zone或者failure-domain.beta.kubernetes.io/region，如果有，則檢查Pod存儲(chǔ)情況。

遍歷Pod需要的存儲(chǔ)信息：

根據(jù)PVC名字獲取PVC信息，取出PVC對(duì)應(yīng)的PV名字，如果沒有名字（表示還未綁定PV），獲取PVC的StorageClassName，如果處理正在綁定中，則跳過不檢查，否則返回匹配失敗（因?yàn)镻VC綁定失?。?/p>

綁定成功的，根據(jù)pvName獲取對(duì)應(yīng)的PV信息，檢查PV的標(biāo)簽，如果PV有上面兩個(gè)標(biāo)簽（zone、region），檢查PV的值中（值可能有多個(gè)，用__分隔），是否包含Node對(duì)應(yīng)標(biāo)簽的值，如果沒有包含，則返回匹配失敗。

14、CheckNodeMemoryPressurePredicate

doesn’t happen often.

-----> 檢查Node內(nèi)存壓力。

15、CheckNodeDiskPressurePredicate

doesn’t happen often.

16、InterPodAffinityMatches

Most expensive predicate to compute.

默認(rèn)有這些打分函數(shù)（priority）：

SelectorSpreadPriority：根據(jù)相同的RC和服務(wù)拆分，使每個(gè)Node具有相同服務(wù)或RC的Pod盡量少，spreads pods by minimizing the number of pods (belonging to the same service or replication controller) on the same node.

InterPodAffinityPriority：根據(jù)Pod共性來分配，pods should be placed in the same topological domain (e.g. same node, same rack, same zone, same power domain, etc.).

LeastRequestedPriority：選擇比較閑的node，Prioritize nodes by least requested utilization.

BalancedResourceAllocation：從資源分配平衡性來考慮分配，Prioritizes nodes to help achieve balanced resource usage.

NodePreferAvoidPodsPriority：用于用戶自定義分配，權(quán)重10000起，方便用戶來指定。0的時(shí)候不起作用。用戶通過這個(gè)來指定：scheduler.alpha.kubernetes.io/preferAvoidPods Set this weight large enough to override all other priority functions.

NodeAffinityPriority：根據(jù)結(jié)點(diǎn)關(guān)系來分配，Prioritizes nodes that have labels matching NodeAffinity.

TaintTolerationPriority：根據(jù)pod設(shè)置的容忍項(xiàng)來分配，Prioritizes nodes that marked with taint which pod can tolerate.

最終，死循環(huán)進(jìn)入：scheduleOne，真正開始schedule的調(diào)度流程。

Schedule調(diào)度流程

先講主流程：

主流程分為以下8步：

1. 從Pod隊(duì)列中取出一個(gè)需要調(diào)度的Pod。

2. 嘗試調(diào)度該P(yáng)od。

3. 調(diào)度失敗，則嘗試搶占Pod。

4. 調(diào)度成功后，嘗試做volumes綁定。

5. 由于reserve插件暫時(shí)未啟用，暫未分析。

6. 嘗試將Pod分配到Node上。

7. 真正實(shí)現(xiàn)綁定。第4步和第6步中，都只是對(duì)schedule的cache的操作，先確保對(duì)cache的操作能完成，最終在第7步，異常實(shí)現(xiàn)將cache中的修改應(yīng)用到apiserver中。如果應(yīng)用失敗，會(huì)將pod的分配信息從cache中清除，重新進(jìn)行scheduler。

8. 最復(fù)雜也最核心的，就是第2步和第3步，下面分別進(jìn)行分析。

調(diào)度Pod流程

調(diào)度Pod，就是嘗試將Pod分配到Node上，流程如下：

共有7點(diǎn)，將逐步分析：

1. Pod基本檢查，檢查Pod是否有了對(duì)應(yīng)的PVC，這里只是檢查PVC是否存在，不關(guān)心綁定過程。

2. 取出所有Node列表。

3. 將nodeInfo應(yīng)用到緩存中。全局nodeInfo中保存了當(dāng)前Node的真實(shí)數(shù)據(jù)信息，而cache中會(huì)有調(diào)度過程的假設(shè)分析的信息。

4. 檢查Pod是否可調(diào)度到Node上，返回可調(diào)度的Node列表。

   a) 這里的檢查，是針對(duì)前面初始化時(shí)，注冊的predicate函數(shù)，如果有不符合，則認(rèn)為不可調(diào)度。

   b) 這里會(huì)嘗試兩次，之所以兩次，是因?yàn)橛小疤崦鸓od”的存在。暫時(shí)先不管“提名Pod”哪來的，后面會(huì)講到。提名Pod，就是說，這個(gè)Pod已經(jīng)分配到Node上，但它還未應(yīng)用到Kubernetes環(huán)境，目前只是占著這個(gè)坑位，要調(diào)度的Pod，在調(diào)度的過程中，也需要考慮它所占的資源。

   c) 第一次時(shí)，會(huì)先把優(yōu)先級(jí)大于當(dāng)前Pod的提名Pod分配到Node中（添加到一個(gè)臨時(shí)的nodeInfo中），然后檢查所有的predicat函數(shù)是否通過。

   d) 第二次時(shí)，不添加提名Pod，再檢查所有的predicate函數(shù)。之所以有第二次，是因?yàn)樘崦鸓od實(shí)際還并不存在，有些Pod親和性可能會(huì)判斷有誤。

   e) 當(dāng)然，如果沒有提名Pod，則不需要第二次判斷。

5. 如果找不到，則返回失敗。如果只找到一個(gè)，則返回該Node。

6. 當(dāng)找到多個(gè)Node時(shí)，會(huì)去給Node打分，打分規(guī)則如下：

   a) 如果沒有定義打分規(guī)則，則返回所有分?jǐn)?shù)都為1。schedule默認(rèn)是有打分函數(shù)的，前面初始化中有講。

   b) 運(yùn)行早期老版本的打分函數(shù)。早期就是單純的一個(gè)function，運(yùn)行后得到打分結(jié)果。

   c) 新版本，將打分函數(shù)拆分成兩步，map和reduce，先按16個(gè)并發(fā)運(yùn)行map，之后運(yùn)行reduce統(tǒng)計(jì)執(zhí)行結(jié)果。

   d) 這里還預(yù)留了擴(kuò)展支持。

   e) 最終返回打分結(jié)果。

7. 根據(jù)打分結(jié)果，選擇Node。

   a) 先取出得分最高的Node列表。

   b) 然后按round-robin的方式選擇Node。

由于相同最高分的Node可能有多個(gè)，genericScheduler采用round-robin的方式：它自己記錄一個(gè)全局的lastNodeIndex，如何num為當(dāng)前有相同最高分的節(jié)點(diǎn)數(shù)，則用lastNodeIndex % num來選取本次節(jié)點(diǎn)的下標(biāo)，之后lastNodeIndex加1，實(shí)現(xiàn)輪詢調(diào)度。

到此，Pod的調(diào)度流程分析完成。當(dāng)中有個(gè)特別的東西：提名Pod（NominatedPod），它的出現(xiàn)和下面講的搶占流程有關(guān)。

Pod搶占流程

搶占的流程，比調(diào)度復(fù)雜一些，主要分兩大步：搶占分析和搶占。第一步是檢查是不是能完成搶占，第二步是執(zhí)行搶占（刪除Pod）。

搶占檢查

1. 檢查Pod是否可以發(fā)起搶占：如果Pod是提名Pod（已經(jīng)預(yù)分配到Node），并且該Node上有處于terminating的Pod p，并且p的優(yōu)先級(jí)小于當(dāng)前Pod，則不允許發(fā)起搶占。

2. 獲取所有Node清單。

3. 獲取可能的Node。檢查調(diào)度失敗原因，如果是nodeNotReady這種原因，則Node不參與搶占。這些都是不參與搶占的：predicates.ErrNodeSelectorNotMatch,predicates.ErrPodAffinityRulesNotMatch,predicates.ErrPodNotMatchHostName,predicates.ErrTaintsTolerationsNotMatch,predicates.ErrNodeLabelPresenceViolated,predicates.ErrNodeNotReady,predicates.ErrNodeNetworkUnavailable,predicates.ErrNodeUnderDiskPressure,predicates.ErrNodeUnderPIDPressure,predicates.ErrNodeUnderMemoryPressure,predicates.ErrNodeUnschedulable,predicates.ErrNodeUnknownCondition,predicates.ErrVolumeZoneConflict,predicates.ErrVolumeNodeConflict,predicates.ErrVolumeBindConflict

4. 如果可搶占的Node沒有，則結(jié)束。

5. 獲取pdb列表：pdb is PodDisruptionBudget. 這個(gè)是預(yù)算的定義，比如statefulset定義了3個(gè)復(fù)本，而我們定義了，允許其中1個(gè)Pod可以掛掉。

6. 獲取通過搶占（刪除一些Pod），能完成調(diào)度的Node列表。
   a) 將比當(dāng)前Pod優(yōu)先級(jí)低的Pod全部從nodeInfoCopy中刪除，然后嘗試去調(diào)度。b) 如果調(diào)度失敗，則表示無法搶占。（因?yàn)椴荒軇h除比它優(yōu)先級(jí)高的）c) 將要?jiǎng)h除的Pod，根據(jù)pdb進(jìn)行拆分：nonViolatingVictim和violatingVictim。說明見圖中。d) 然后嘗試將violatingVictim中的Pod一個(gè)個(gè)加進(jìn)去，嘗試能不能調(diào)度。numViolatingVictim中記錄不通過數(shù)。e) 然后嘗試將nonViolatingVictim中的Pod一個(gè)個(gè)加進(jìn)去，嘗試能不能調(diào)度。victims記錄不通過的Pod信息。f) 返回victims和numViolatingVictim。

7. extenders擴(kuò)展保留。

8. 從可搶占的Node列表中，選擇最合適的一個(gè)Node。按如下規(guī)則進(jìn)行選擇：a) node pdb violations最小。就是上面返回的numViolatingVictimb) 如果只有一個(gè)Node滿足，則返回該Nodec) 比較Node中victims中優(yōu)先級(jí)的最高值，取最小的那個(gè)。最高：取的是單個(gè)Node中，優(yōu)先級(jí)的最高值。最?。喝〉氖撬蠳ode中的最小值d) 如果只有一個(gè)，則返回該Node。e) 取Node中victims優(yōu)先級(jí)總和最小的。f) 如果只有一個(gè)，則返回該Node。g) 取Node中victims的Pod數(shù)最小的。h) 返回第一個(gè)。

9. 如果無合適的，則結(jié)束。

10. 獲取比當(dāng)前優(yōu)先級(jí)小的提名Pod。

11. 返回Node信息，需要?jiǎng)h除的Pod列表，優(yōu)先級(jí)小的提名Pod。
    
    

到此，搶占檢查結(jié)束。得到期望調(diào)度的Node、要調(diào)度到這個(gè)Node上，需要?jiǎng)h除的Pod列表、以及比當(dāng)前Pod優(yōu)先級(jí)小的提名Pod。

搶占執(zhí)行流程（找到了期望的Node才會(huì)進(jìn)入）

1. 將當(dāng)前Pod，變更為提名Pod，對(duì)應(yīng)的Node為期望的Node。這里就是提名Pod出現(xiàn)的原因。
2. 將提名Pod信息更新到apiServer。
3. 遍歷victims（搶占流程返回的需要?jiǎng)h除的Pod列表），刪除Pod，并記錄event。
4. 遍歷nominatedPodsToClear（搶占返回的比當(dāng)前Pod優(yōu)先級(jí)小的提名Pod），清空提名Pod配置，并更新apiServer。

到此，調(diào)度流程分析完成。

關(guān)于Kubernetes scheduler學(xué)習(xí)筆記是怎樣的問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道了解更多相關(guān)知識(shí)。

當(dāng)前題目：Kubernetesscheduler學(xué)習(xí)筆記是怎樣的-創(chuàng)新互聯(lián)
網(wǎng)站URL：http://jinyejixie.com/article22/ccjhjc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站策劃、網(wǎng)站制作、建站公司、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)