Kubernetes scheduler學(xué)習(xí)筆記是怎樣的，針對這個問題，這篇文章詳細介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
富民ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：13518219792（備注：SSL證書合作）期待與您的合作！Kubernetes是一個強大的編排工具，可以用來很方便的管理許多臺機器，為了使機器的資源利用率提高，同時也盡可能的把壓力分攤到各個機器上，這個職責(zé)就是由scheduler來完成的。
Kubernetes scheduler是一個策略豐富、拓撲感知、工作負載特定的功能，顯著影響可用性、性能和容量。
為了能更好的使用它，所以從源碼的角度，對它進行一個全方位的分析與學(xué)習(xí)。
scheduler的功能不多，但邏輯比較復(fù)雜，里面有很多考慮的因素，總結(jié)下來大致有如下幾點：
Leader選主，確保集群中只有一個scheduler在工作，其它只是高可用備份實例。通過endpoint:kube-scheduler作為仲裁資源。
Node篩選，根據(jù)設(shè)置的條件、資源要求等，匹配出所有滿足分配的Node結(jié)點。
最優(yōu)Node選擇。在所有滿足條件的Node中，根據(jù)定義好的規(guī)則來打分，取分數(shù)最高的。如果有相同分數(shù)的，則采用輪詢方式。
為了響應(yīng)高優(yōu)先級的資源分配，增加了搶占功能。scheduler有權(quán)刪除一些低優(yōu)先級的Pod，以釋放資源給高優(yōu)先級的Pod來使用。
代碼看下來比較困難，下面將分幾個場景來描述scheduler工作的過程：
1、環(huán)境說明（假設(shè)3臺機器，分別是8C16G）
場景一：資源分配——最基本的功能
2、先分配一個請求2C4G的Pod：A
場景二：機器負載均衡——評分機制
3、再分配一個請求2C4G的Pod：B（盡管node1上還有空閑資源可分配B，但node2和node3空閑資源更多，打分更高，所以分配到了node2<選擇node2還是node3，是由schedule輪詢選擇的>。）
4、同理，如果再分配一個C，scheduler會優(yōu)先分配到node3上
場景三：資源搶占——特權(quán)機制
5、現(xiàn)在3個Node上都分配了2C4G，就是都剩余6C12G，如果我這個時候分配一個8C12G的Pod：D，在同優(yōu)先級的情況下，D將不會分配，處于Pending狀態(tài)，因為三臺機器都資源不足。
6、如果這個時候，我給D設(shè)置一個高的優(yōu)先級，schedule會刪除一臺機器上的Pod，比如A，然后資源足夠了，將D分配到node1上，再將A分配到node2或node3上。（這里分配是一個類似，因為三臺都是一樣的）
7、下面實戰(zhàn)一把，詳細試驗下scheduler的搶占過程：
我有一個Deployment，有3個復(fù)本，分別分配到兩臺機器上。（為什么用這個例子，是為了說明，搶占一定會發(fā)生在10-10-40-89上，因為要刪除的Pod最少）
這個時候，我創(chuàng)建一個高優(yōu)先級的Deployment：
快速查詢，能看到下面的階段：
第一步，將要分配的testpc-745cc7867-fqbp2設(shè)置為“提名Pod”，這個名字后面會再出現(xiàn)，同時刪除原10-10-40-89上的testpod，由于截的比較慢，下圖中新的testpod已經(jīng)在10-10-88-99上創(chuàng)建了。
第二步，提名Pod將會分配到對應(yīng)的結(jié)點上（等待Terminating狀態(tài)的Pod釋放完資源后）。
第三步，資源足夠，Pod正常Running。
最后展示下watch情況下的事件：
測試我共有兩個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時，考慮的要素很多，親和性和反親和，是一個比較常用的，在這里做一個典型來講講。
比如在上圖中，我新的Pod：D，要求不能和A在一臺機器上，和B的互斥打分是100，和C的互斥打分是10。表示說，D一定不能和A在一臺機器，盡可能不和B、C在同一臺機器，實在沒辦法時（資源不足），D更傾向于和C在一起。
樣例：
podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: security operator: In values: - S2 topologyKey: kubernetes.io/hostname
通過對這四個應(yīng)用場景的分析，對它的功能有了一個初步的了解。要想更全面、深入的了解它的功能，需要從它的源碼來著手。下面將從源碼層面來做深入分析。
scheduler的配置，基本都是采用默認配置，圖中列出了它的配置加載流程，基本都是加載它自身的默認配置。
server.Run為它的主體邏輯，之后會詳細講解。
重要配置講解
圖中，單獨列出了兩個config配置：
1、disablePreemption：
scheduler有個搶占功能。當(dāng)Pod調(diào)度發(fā)現(xiàn)無可用資源時，它會將比該Pod優(yōu)先級低的Pod刪除，以釋放資源給它來調(diào)度。disablePreemption默認為false，表示開啟搶占，如果需要關(guān)閉，則設(shè)置為true。
2、既然說到優(yōu)先級，所以我還列出來了優(yōu)先級的設(shè)置方法。
Kubernetes中有個單獨的優(yōu)先級的資源，叫：PriorityClass，通過下面這個yaml，能創(chuàng)建一個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."
然后可將這個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)先級的設(shè)置。如果不設(shè)置，Pod默認是同一優(yōu)先級（為0）。
特別注意：
static Pod比較特殊，需要直接設(shè)置priority，因為kubelet是根據(jù)priority來判斷。
scheduler啟動流程
通過深入分析server.Run，可看到如下流程：
server.Run還是有一部分的配置處理流程。
schedulerConfig中，根據(jù)默認的參數(shù)，加載了兩大塊內(nèi)容：predicate、priority函數(shù)。
predicate函數(shù)用于做Pod是否可分配到Node上的檢查函數(shù)。
priority函數(shù)，則用于選優(yōu)。當(dāng)可分配的Node有多個時，這個時候就會根據(jù)priority函數(shù)來給node打分，最終調(diào)度到分數(shù)最高的Node上。
Kubernetes提供了這些默認的判斷函數(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，則認為結(jié)點為notReady
如果Node類型為OutOfDisk，并且狀態(tài)不是False，則認為結(jié)點OutOfDisk
如果Node類型為NetworkUnavailable，并且狀態(tài)不是False，則認為結(jié)點狀態(tài)為：NetworkUnavailable
檢查Node的spec，如果是UnSchedulable，則認為結(jié)點為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é)點親和關(guān)系：
如果未定義requiredDuringSchedulingIgnoredDuringExecution，則直接返回匹配。
如果定義了requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms，則里面有一個匹配，則匹配。否則認為不匹配。
特別的：如果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是否超過，如果超過，增加超限錯誤（此處未直接返回，會把所有錯誤檢查完一次性返回）。
檢查元數(shù)據(jù)中是否有定義podRequest、ignoredExtendedResources，如果定義了，則從元數(shù)據(jù)中取。否則從Pod中每個容器中?。合葯z查所有container中所有需要的資源總合，再檢查initContainer中，如果有資源比總合還大，則取較大的為所需要的資源。
如果需要的資源都為0，則返回檢查結(jié)果。
獲取Node的可用資源，檢查需要新申請的資源+已申請的資源是否超過可用資源，如果超過，則記錄資源不足。
檢查所有Pod擴展資源，并判斷擴展資源是否需要檢查（ignoredExtendedResources），如果需要檢查，則判斷資源是否足夠，不足夠則記錄失敗。
返回檢查結(jié)果（如果無失敗，是檢查成功）。
6、NoDiskConflict
Following the resource predicate, we check disk.
----> 遍歷Pod所有存儲、Node下的所有Pod，檢查是否有存儲沖突：
如果Pod無存儲（無GCE、AWS、RBD、ISCSI），則檢查通過。
7、PodToleratesNodeTaints
check toleration here, as node might have toleration.
-----> 檢查結(jié)點是否容忍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é)點的taint狀態(tài)。檢查步驟：
如果effect為空，則檢查通過，否則要相同。
如果key為空，則檢查通過，否則要相同。
如果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)心值?？稍O(shè)置label存在與不存在。
只有在scheduler.CreateFromConfig(policy)才會初始化該檢查，在RegisterCustomFitPredicate中注冊，默認無該檢查。
10、checkServiceAffinity
-----> 檢查服務(wù)類同關(guān)系。
如果一個Pod的服務(wù)調(diào)度到有l(wèi)abel:"region=foo"的Node，之后有相同服務(wù)的Pod都會調(diào)度到該Node。
11、MaxPDVolumeCountPredicate
-----> 檢查掛載的卷個數(shù)是不是超標，只支持：ESB：39，GCE：16，AzureDisk：16。
12、VolumeNodePredicate
-----> 無
13、VolumeZonePredicate
-----> 檢查存儲區(qū)域劃分：
檢查Node中是否有l(wèi)abel：failure-domain.beta.kubernetes.io/zone或者failure-domain.beta.kubernetes.io/region，如果有，則檢查Pod存儲情況。
遍歷Pod需要的存儲信息：
根據(jù)PVC名字獲取PVC信息，取出PVC對應(yīng)的PV名字，如果沒有名字（表示還未綁定PV），獲取PVC的StorageClassName，如果處理正在綁定中，則跳過不檢查，否則返回匹配失?。ㄒ驗镻VC綁定失敗）。
綁定成功的，根據(jù)pvName獲取對應(yīng)的PV信息，檢查PV的標簽，如果PV有上面兩個標簽（zone、region），檢查PV的值中（值可能有多個，用__分隔），是否包含Node對應(yīng)標簽的值，如果沒有包含，則返回匹配失敗。
14、CheckNodeMemoryPressurePredicate
doesn’t happen often.
-----> 檢查Node內(nèi)存壓力。
15、CheckNodeDiskPressurePredicate
doesn’t happen often.
16、InterPodAffinityMatches
Most expensive predicate to compute.
默認有這些打分函數(shù)（priority）：
SelectorSpreadPriority：根據(jù)相同的RC和服務(wù)拆分，使每個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的時候不起作用。用戶通過這個來指定：scheduler.alpha.kubernetes.io/preferAvoidPods Set this weight large enough to override all other priority functions.
NodeAffinityPriority：根據(jù)結(jié)點關(guān)系來分配，Prioritizes nodes that have labels matching NodeAffinity.
TaintTolerationPriority：根據(jù)pod設(shè)置的容忍項來分配，Prioritizes nodes that marked with taint which pod can tolerate.
最終，死循環(huán)進入：scheduleOne，真正開始schedule的調(diào)度流程。
Schedule調(diào)度流程
先講主流程：
主流程分為以下8步：
從Pod隊列中取出一個需要調(diào)度的Pod。
嘗試調(diào)度該Pod。
調(diào)度失敗，則嘗試搶占Pod。
調(diào)度成功后，嘗試做volumes綁定。
由于reserve插件暫時未啟用，暫未分析。
嘗試將Pod分配到Node上。
真正實現(xiàn)綁定。第4步和第6步中，都只是對schedule的cache的操作，先確保對cache的操作能完成，最終在第7步，異常實現(xiàn)將cache中的修改應(yīng)用到apiserver中。如果應(yīng)用失敗，會將pod的分配信息從cache中清除，重新進行scheduler。
最復(fù)雜也最核心的，就是第2步和第3步，下面分別進行分析。
調(diào)度Pod流程
調(diào)度Pod，就是嘗試將Pod分配到Node上，流程如下：
共有7點，將逐步分析：Pod基本檢查，檢查Pod是否有了對應(yīng)的PVC，這里只是檢查PVC是否存在，不關(guān)心綁定過程。
取出所有Node列表。
將nodeInfo應(yīng)用到緩存中。全局nodeInfo中保存了當(dāng)前Node的真實數(shù)據(jù)信息，而cache中會有調(diào)度過程的假設(shè)分析的信息。
檢查Pod是否可調(diào)度到Node上，返回可調(diào)度的Node列表。
a) 這里的檢查，是針對前面初始化時，注冊的predicate函數(shù)，如果有不符合，則認為不可調(diào)度。
b) 這里會嘗試兩次，之所以兩次，是因為有“提名Pod”的存在。暫時先不管“提名Pod”哪來的，后面會講到。提名Pod，就是說，這個Pod已經(jīng)分配到Node上，但它還未應(yīng)用到Kubernetes環(huán)境，目前只是占著這個坑位，要調(diào)度的Pod，在調(diào)度的過程中，也需要考慮它所占的資源。
c) 第一次時，會先把優(yōu)先級大于當(dāng)前Pod的提名Pod分配到Node中（添加到一個臨時的nodeInfo中），然后檢查所有的predicat函數(shù)是否通過。
d) 第二次時，不添加提名Pod，再檢查所有的predicate函數(shù)。之所以有第二次，是因為提名Pod實際還并不存在，有些Pod親和性可能會判斷有誤。
e) 當(dāng)然，如果沒有提名Pod，則不需要第二次判斷。
如果找不到，則返回失敗。如果只找到一個，則返回該Node。
當(dāng)找到多個Node時，會去給Node打分，打分規(guī)則如下：
a) 如果沒有定義打分規(guī)則，則返回所有分數(shù)都為1。schedule默認是有打分函數(shù)的，前面初始化中有講。
b) 運行早期老版本的打分函數(shù)。早期就是單純的一個function，運行后得到打分結(jié)果。
c) 新版本，將打分函數(shù)拆分成兩步，map和reduce，先按16個并發(fā)運行map，之后運行reduce統(tǒng)計執(zhí)行結(jié)果。
d) 這里還預(yù)留了擴展支持。
e) 最終返回打分結(jié)果。
根據(jù)打分結(jié)果，選擇Node。
a) 先取出得分最高的Node列表。
b) 然后按round-robin的方式選擇Node。
由于相同最高分的Node可能有多個，genericScheduler采用round-robin的方式：它自己記錄一個全局的lastNodeIndex，如何num為當(dāng)前有相同最高分的節(jié)點數(shù)，則用lastNodeIndex % num來選取本次節(jié)點的下標，之后lastNodeIndex加1，實現(xiàn)輪詢調(diào)度。
到此，Pod的調(diào)度流程分析完成。當(dāng)中有個特別的東西：提名Pod（NominatedPod），它的出現(xiàn)和下面講的搶占流程有關(guān)。
Pod搶占流程
搶占的流程，比調(diào)度復(fù)雜一些，主要分兩大步：搶占分析和搶占。第一步是檢查是不是能完成搶占，第二步是執(zhí)行搶占（刪除Pod）。
搶占檢查
檢查Pod是否可以發(fā)起搶占：如果Pod是提名Pod（已經(jīng)預(yù)分配到Node），并且該Node上有處于terminating的Pod p，并且p的優(yōu)先級小于當(dāng)前Pod，則不允許發(fā)起搶占。
獲取所有Node清單。
如果可搶占的Node沒有，則結(jié)束。
獲取pdb列表：pdb is PodDisruptionBudget. 這個是預(yù)算的定義，比如statefulset定義了3個復(fù)本，而我們定義了，允許其中1個Pod可以掛掉。
到此，搶占檢查結(jié)束。得到期望調(diào)度的Node、要調(diào)度到這個Node上，需要刪除的Pod列表、以及比當(dāng)前Pod優(yōu)先級小的提名Pod。
搶占執(zhí)行流程（找到了期望的Node才會進入）
到此，調(diào)度流程分析完成。
關(guān)于Kubernetes scheduler學(xué)習(xí)筆記是怎樣的問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道了解更多相關(guān)知識。
重慶分公司
重慶分公司
