溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
Kubernetes scheduler學習筆記是怎樣的，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
Kubernetes是一個強大的編排工具，可以用來很方便的管理許多臺機器，為了使機器的資源利用率提高，同時也盡可能的把壓力分攤到各個機器上，這個職責就是由scheduler來完成的。
Kubernetes scheduler是一個策略豐富、拓撲感知、工作負載特定的功能，顯著影響可用性、性能和容量。
為了能更好的使用它，所以從源碼的角度，對它進行一個全方位的分析與學習。
scheduler的功能不多，但邏輯比較復雜，里面有很多考慮的因素，總結下來大致有如下幾點：
Leader選主，確保集群中只有一個scheduler在工作，其它只是高可用備份實例。通過endpoint:kube-scheduler作為仲裁資源。
Node篩選，根據設置的條件、資源要求等，匹配出所有滿足分配的Node結點。
最優Node選擇。在所有滿足條件的Node中，根據定義好的規則來打分，取分數最高的。如果有相同分數的，則采用輪詢方式。
為了響應高優先級的資源分配，增加了搶占功能。scheduler有權刪除一些低優先級的Pod，以釋放資源給高優先級的Pod來使用。
代碼看下來比較困難，下面將分幾個場景來描述scheduler工作的過程：
1、環境說明（假設3臺機器，分別是8C16G）
場景一：資源分配——最基本的功能
2、先分配一個請求2C4G的Pod：A
場景二：機器負載均衡——評分機制
3、再分配一個請求2C4G的Pod：B（盡管node1上還有空閑資源可分配B，但node2和node3空閑資源更多，打分更高，所以分配到了node2<選擇node2還是node3，是由schedule輪詢選擇的>。）
4、同理，如果再分配一個C，scheduler會優先分配到node3上
場景三：資源搶占——特權機制
5、現在3個Node上都分配了2C4G，就是都剩余6C12G，如果我這個時候分配一個8C12G的Pod：D，在同優先級的情況下，D將不會分配，處于Pending狀態，因為三臺機器都資源不足。
6、如果這個時候，我給D設置一個高的優先級，schedule會刪除一臺機器上的Pod，比如A，然后資源足夠了，將D分配到node1上，再將A分配到node2或node3上。（這里分配是一個類似，因為三臺都是一樣的）
7、下面實戰一把，詳細試驗下scheduler的搶占過程：
我有一個Deployment，有3個復本，分別分配到兩臺機器上。（為什么用這個例子，是為了說明，搶占一定會發生在10-10-40-89上，因為要刪除的Pod最少）
這個時候，我創建一個高優先級的Deployment：
快速查詢，能看到下面的階段：
第一步，將要分配的testpc-745cc7867-fqbp2設置為“提名Pod”，這個名字后面會再出現，同時刪除原10-10-40-89上的testpod，由于截的比較慢，下圖中新的testpod已經在10-10-88-99上創建了。
第二步，提名Pod將會分配到對應的結點上（等待Terminating狀態的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
場景四：關系戶——親和與反親和
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
通過對這四個應用場景的分析，對它的功能有了一個初步的了解。要想更全面、深入的了解它的功能，需要從它的源碼來著手。下面將從源碼層面來做深入分析。
scheduler的配置，基本都是采用默認配置，圖中列出了它的配置加載流程，基本都是加載它自身的默認配置。
server.Run為它的主體邏輯，之后會詳細講解。
重要配置講解
圖中，單獨列出了兩個config配置：
1、disablePreemption：
scheduler有個搶占功能。當Pod調度發現無可用資源時，它會將比該Pod優先級低的Pod刪除，以釋放資源給它來調度。disablePreemption默認為false，表示開啟搶占，如果需要關閉，則設置為true。
2、既然說到優先級，所以我還列出來了優先級的設置方法。
Kubernetes中有個單獨的優先級的資源，叫：PriorityClass，通過下面這個yaml，能創建一個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關聯到Pod上：
apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent priorityClassName: high-priority
這樣就完成的Pod優先級的設置。如果不設置，Pod默認是同一優先級（為0）。
特別注意：
static Pod比較特殊，需要直接設置priority，因為kubelet是根據priority來判斷。
scheduler啟動流程
通過深入分析server.Run，可看到如下流程：
server.Run還是有一部分的配置處理流程。
schedulerConfig中，根據默認的參數，加載了兩大塊內容：predicate、priority函數。
predicate函數用于做Pod是否可分配到Node上的檢查函數。
priority函數，則用于選優。當可分配的Node有多個時，這個時候就會根據priority函數來給node打分，最終調度到分數最高的Node上。
Kubernetes提供了這些默認的判斷函數：
predicate：
1、CheckNodeConditionPredicate
we really don’t want to check predicates against unschedulable nodes.
檢查Node狀態：是否處于可調度狀態等。
-----> 遍歷nodeInfo中Node的所有狀況：
如果Node類型為ready，并且狀態不是True，則認為結點為notReady
如果Node類型為OutOfDisk，并且狀態不是False，則認為結點OutOfDisk
如果Node類型為NetworkUnavailable，并且狀態不是False，則認為結點狀態為：NetworkUnavailable
檢查Node的spec，如果是UnSchedulable，則認為結點為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.
檢查服務端口是否被占用。
-----> 如果元數據metadata中有定義需要的podPorts，則直接從元數據中取，否則從Pod的所有容器中獲取需要的port。
如果需要的port為空，則返回匹配成功。
從nodeInfo中獲取當前已經使用的port，如果有沖突，則返回：端口不匹配，否則返回匹配成功。
4、PodMatchNodeSelector
check node label after narrowing search.
檢查label是否匹配。
------> 如果Pod中定義了NodeSelector，則根據選擇來匹配Node的labels，如果不匹配，則返回NodeSelectorNotMatch。
如果Pod的Affinity中定義了NodeAffinity，則檢查結點親和關系：
如果未定義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是否超過，如果超過，增加超限錯誤（此處未直接返回，會把所有錯誤檢查完一次性返回）。
檢查元數據中是否有定義podRequest、ignoredExtendedResources，如果定義了，則從元數據中取。否則從Pod中每個容器中取：先檢查所有container中所有需要的資源總合，再檢查initContainer中，如果有資源比總合還大，則取較大的為所需要的資源。
如果需要的資源都為0，則返回檢查結果。
獲取Node的可用資源，檢查需要新申請的資源+已申請的資源是否超過可用資源，如果超過，則記錄資源不足。
檢查所有Pod擴展資源，并判斷擴展資源是否需要檢查（ignoredExtendedResources），如果需要檢查，則判斷資源是否足夠，不足夠則記錄失敗。
返回檢查結果（如果無失敗，是檢查成功）。
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.
-----> 檢查結點是否容忍taint環境：
參數：Pod中定義的容忍規則：tolerations，Node中的環境狀態：taints，篩選規則：取effect為NoSchedule、NoExecute的。
如果Node無taints，返回匹配成功。
遍歷所有taints，如果taint不滿足篩選規則，則跳過檢查。
遍歷所有的容忍規則，檢查是否有規則是允許結點的taint狀態。檢查步驟：
如果effect為空，則檢查通過，否則要相同。
如果key為空，則檢查通過，否則要相同。
如果operator為Exists，則檢查通過，如果為空或者是Equal，則要相同，否則不通過。
8、PodToleratesNodeNoExecuteTaints
check toleration here, as node might have toleration.
-----> 檢查規則同上相似，只是篩選規則變了：取effect為NoExecute的。
9、CheckNodeLabelPresence
labels are easy to check, so this one goes before.
------> 檢查label是否存在，不關心值。可設置label存在與不存在。
只有在scheduler.CreateFromConfig(policy)才會初始化該檢查，在RegisterCustomFitPredicate中注冊，默認無該檢查。
10、checkServiceAffinity
-----> 檢查服務類同關系。
如果一個Pod的服務調度到有label:"region=foo"的Node，之后有相同服務的Pod都會調度到該Node。
11、MaxPDVolumeCountPredicate
-----> 檢查掛載的卷個數是不是超標，只支持：ESB：39，GCE：16，AzureDisk：16。
12、VolumeNodePredicate
-----> 無
13、VolumeZonePredicate
-----> 檢查存儲區域劃分：
檢查Node中是否有label：failure-domain.beta.kubernetes.io/zone或者failure-domain.beta.kubernetes.io/region，如果有，則檢查Pod存儲情況。
遍歷Pod需要的存儲信息：
根據PVC名字獲取PVC信息，取出PVC對應的PV名字，如果沒有名字（表示還未綁定PV），獲取PVC的StorageClassName，如果處理正在綁定中，則跳過不檢查，否則返回匹配失敗（因為PVC綁定失敗）。
綁定成功的，根據pvName獲取對應的PV信息，檢查PV的標簽，如果PV有上面兩個標簽（zone、region），檢查PV的值中（值可能有多個，用__分隔），是否包含Node對應標簽的值，如果沒有包含，則返回匹配失敗。
14、CheckNodeMemoryPressurePredicate
doesn’t happen often.
-----> 檢查Node內存壓力。
15、CheckNodeDiskPressurePredicate
doesn’t happen often.
16、InterPodAffinityMatches
Most expensive predicate to compute.
默認有這些打分函數（priority）：
SelectorSpreadPriority：根據相同的RC和服務拆分，使每個Node具有相同服務或RC的Pod盡量少，spreads pods by minimizing the number of pods (belonging to the same service or replication controller) on the same node.
InterPodAffinityPriority：根據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：用于用戶自定義分配，權重10000起，方便用戶來指定。0的時候不起作用。用戶通過這個來指定：scheduler.alpha.kubernetes.io/preferAvoidPods Set this weight large enough to override all other priority functions.
NodeAffinityPriority：根據結點關系來分配，Prioritizes nodes that have labels matching NodeAffinity.
TaintTolerationPriority：根據pod設置的容忍項來分配，Prioritizes nodes that marked with taint which pod can tolerate.
最終，死循環進入：scheduleOne，真正開始schedule的調度流程。
Schedule調度流程
先講主流程：
主流程分為以下8步：
從Pod隊列中取出一個需要調度的Pod。
嘗試調度該Pod。
調度失敗，則嘗試搶占Pod。
調度成功后，嘗試做volumes綁定。
由于reserve插件暫時未啟用，暫未分析。
嘗試將Pod分配到Node上。
真正實現綁定。第4步和第6步中，都只是對schedule的cache的操作，先確保對cache的操作能完成，最終在第7步，異常實現將cache中的修改應用到apiserver中。如果應用失敗，會將pod的分配信息從cache中清除，重新進行scheduler。
最復雜也最核心的，就是第2步和第3步，下面分別進行分析。
調度Pod流程
調度Pod，就是嘗試將Pod分配到Node上，流程如下：
Pod基本檢查，檢查Pod是否有了對應的PVC，這里只是檢查PVC是否存在，不關心綁定過程。
取出所有Node列表。
將nodeInfo應用到緩存中。全局nodeInfo中保存了當前Node的真實數據信息，而cache中會有調度過程的假設分析的信息。
檢查Pod是否可調度到Node上，返回可調度的Node列表。
a) 這里的檢查，是針對前面初始化時，注冊的predicate函數，如果有不符合，則認為不可調度。
b) 這里會嘗試兩次，之所以兩次，是因為有“提名Pod”的存在。暫時先不管“提名Pod”哪來的，后面會講到。提名Pod，就是說，這個Pod已經分配到Node上，但它還未應用到Kubernetes環境，目前只是占著這個坑位，要調度的Pod，在調度的過程中，也需要考慮它所占的資源。
c) 第一次時，會先把優先級大于當前Pod的提名Pod分配到Node中（添加到一個臨時的nodeInfo中），然后檢查所有的predicat函數是否通過。
d) 第二次時，不添加提名Pod，再檢查所有的predicate函數。之所以有第二次，是因為提名Pod實際還并不存在，有些Pod親和性可能會判斷有誤。
e) 當然，如果沒有提名Pod，則不需要第二次判斷。
如果找不到，則返回失敗。如果只找到一個，則返回該Node。
當找到多個Node時，會去給Node打分，打分規則如下：
a) 如果沒有定義打分規則，則返回所有分數都為1。schedule默認是有打分函數的，前面初始化中有講。
b) 運行早期老版本的打分函數。早期就是單純的一個function，運行后得到打分結果。
c) 新版本，將打分函數拆分成兩步，map和reduce，先按16個并發運行map，之后運行reduce統計執行結果。
d) 這里還預留了擴展支持。
e) 最終返回打分結果。
根據打分結果，選擇Node。
a) 先取出得分最高的Node列表。
b) 然后按round-robin的方式選擇Node。
由于相同最高分的Node可能有多個，genericScheduler采用round-robin的方式：它自己記錄一個全局的lastNodeIndex，如何num為當前有相同最高分的節點數，則用lastNodeIndex % num來選取本次節點的下標，之后lastNodeIndex加1，實現輪詢調度。
到此，Pod的調度流程分析完成。當中有個特別的東西：提名Pod（NominatedPod），它的出現和下面講的搶占流程有關。
Pod搶占流程
搶占的流程，比調度復雜一些，主要分兩大步：搶占分析和搶占。第一步是檢查是不是能完成搶占，第二步是執行搶占（刪除Pod）。
搶占檢查
檢查Pod是否可以發起搶占：如果Pod是提名Pod（已經預分配到Node），并且該Node上有處于terminating的Pod p，并且p的優先級小于當前Pod，則不允許發起搶占。
獲取所有Node清單。
如果可搶占的Node沒有，則結束。
獲取pdb列表：pdb is PodDisruptionBudget. 這個是預算的定義，比如statefulset定義了3個復本，而我們定義了，允許其中1個Pod可以掛掉。
到此，搶占檢查結束。得到期望調度的Node、要調度到這個Node上，需要刪除的Pod列表、以及比當前Pod優先級小的提名Pod。
搶占執行流程（找到了期望的Node才會進入）
到此，調度流程分析完成。
關于Kubernetes scheduler學習筆記是怎樣的問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
