當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

Kubernetes 是如何调度的？

發(fā)布時(shí)間：2024/8/23 编程问答 39 豆豆

生活随笔收集整理的這篇文章主要介紹了 Kubernetes 是如何调度的？小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

作者?|?阿文，責(zé)編 | 郭芮

頭圖 | CSDN 下載自東方IC

出品 | CSDN（ID：CSDNnews）

自互聯(lián)網(wǎng)出現(xiàn)以來，云計(jì)算的概念已經(jīng)提出了有 50 年。從1957 年，John McCarthy 將計(jì)算機(jī)中的分時(shí)共享概念設(shè)計(jì)成了一種工具。從此以后，這個(gè)概念的名字經(jīng)歷過數(shù)次變化：從“服務(wù)中心（service bureau）”到應(yīng)用服務(wù)提供商，到互聯(lián)網(wǎng)即服務(wù)，到云計(jì)算，再到軟件定義的數(shù)據(jù)中心。

一直以來基礎(chǔ)設(shè)施是云計(jì)算的基礎(chǔ)核心，基礎(chǔ)設(shè)施服務(wù)（Infrastructure as a Service，IaaS）將IT基礎(chǔ)設(shè)施資源（計(jì)算、網(wǎng)絡(luò)與存儲(chǔ)）以一種彈性的服務(wù)方式對(duì)外提供。近十余年來隨著云計(jì)算不斷發(fā)展與落地，云基礎(chǔ)設(shè)施技術(shù)架構(gòu)也在不斷往前演進(jìn)，從傳統(tǒng)虛擬化、基礎(chǔ)設(shè)施資源管理走向軟件定義架構(gòu)。隨著近5年來以容器和微服務(wù)為代表的云原生技術(shù)興起，云基礎(chǔ)設(shè)施架構(gòu)需要演進(jìn)以全面擁抱云原生技術(shù)。

以容器、容器編排、微服務(wù)、服務(wù)網(wǎng)格為代表的云原生技術(shù)正在日益體現(xiàn)出期在云計(jì)算領(lǐng)域的非凡價(jià)值，眾所周知，容器編排中 Kubernetes 已經(jīng)成為容器編排領(lǐng)域的事實(shí)標(biāo)準(zhǔn)。

kubernetes 可以提供所需的編排和管理功能，以便針對(duì)工作負(fù)載大規(guī)模部署容器。借助 Kubernetes 編排功能，可以快速的構(gòu)建跨多個(gè)容器的應(yīng)用服務(wù)、跨集群調(diào)度、擴(kuò)展這些容器，并長(zhǎng)期持續(xù)管理這些容器的健康狀況。在 Kubernetes 中，調(diào)度?是指將 Pod 放置到合適的 Node上，然后對(duì)應(yīng) Node 上的 Kubelet才能夠運(yùn)行這些 pod。

那么kubernetes 是如何進(jìn)行調(diào)度的呢？我們來一起看下。

Kubernetes ?是如何調(diào)度的？

kube-scheduler 是 Kubernetes 集群的默認(rèn)調(diào)度器，并且是集群控制面的一部分。同時(shí) kube-scheduler 在設(shè)計(jì)上是允許你自己寫一個(gè)調(diào)度組件并替換原有的 kube-scheduler。

對(duì)每一個(gè)新創(chuàng)建的 Pod 或者是未被調(diào)度的 Pod，kube-scheduler 會(huì)選擇一個(gè)最優(yōu)的 Node 去運(yùn)行這個(gè) Pod。那么kube-scheduler 是如何選擇最優(yōu)的 Node 呢？

kube-scheduler監(jiān)聽apiserver的/api/pod/，當(dāng)發(fā)現(xiàn)集群中有未得到調(diào)度的pod(即PodSpec.NodeName為空)時(shí)，會(huì)查詢集群各node的信息，經(jīng)過Predicates(過濾)、Priorities(優(yōu)選器)，得到最適合該pod運(yùn)行的node后，再向apiserver發(fā)送請(qǐng)求，將該容器綁定到選中的node上。

Kubernetes Scheduler 提供的調(diào)度流程分三步：

過濾，遍歷nodelist，選擇出符合要求的候選節(jié)點(diǎn)，Kubernetes內(nèi)置了多種預(yù)選規(guī)則供用戶選擇。
打分，在選擇出符合要求的候選節(jié)點(diǎn)中，采用優(yōu)選規(guī)則計(jì)算出每個(gè)節(jié)點(diǎn)的積分，最后選擇得分最高的。
綁定， ?選出其中得分最高的 Node 來運(yùn)行 Pod。之后，調(diào)度器將這個(gè)調(diào)度決定通知給 kube-apiserver，這個(gè)過程叫做綁定。

整個(gè)過程，如圖所示：

預(yù)選的算法可以參考源碼predicates.go（https://github.com/kubernetes/kubernetes/blob/master/pkg/scheduler/algorithm/predicates/predicates.go）：

const?(//?MatchInterPodAffinityPred?defines?the?name?of?predicate?MatchInterPodAffinity.MatchInterPodAffinityPred?=?"MatchInterPodAffinity"//?CheckVolumeBindingPred?defines?the?name?of?predicate?CheckVolumeBinding.CheckVolumeBindingPred?=?"CheckVolumeBinding"//?GeneralPred?defines?the?name?of?predicate?GeneralPredicates.GeneralPred?=?"GeneralPredicates"//?HostNamePred?defines?the?name?of?predicate?HostName.HostNamePred?=?"HostName"//?PodFitsHostPortsPred?defines?the?name?of?predicate?PodFitsHostPorts.PodFitsHostPortsPred?=?"PodFitsHostPorts"//?MatchNodeSelectorPred?defines?the?name?of?predicate?MatchNodeSelector.MatchNodeSelectorPred?=?"MatchNodeSelector"//?PodFitsResourcesPred?defines?the?name?of?predicate?PodFitsResources.PodFitsResourcesPred?=?"PodFitsResources"//?NoDiskConflictPred?defines?the?name?of?predicate?NoDiskConflict.NoDiskConflictPred?=?"NoDiskConflict"//?PodToleratesNodeTaintsPred?defines?the?name?of?predicate?PodToleratesNodeTaints.PodToleratesNodeTaintsPred?=?"PodToleratesNodeTaints"//?CheckNodeUnschedulablePred?defines?the?name?of?predicate?CheckNodeUnschedulablePredicate.CheckNodeUnschedulablePred?=?"CheckNodeUnschedulable"//?CheckNodeLabelPresencePred?defines?the?name?of?predicate?CheckNodeLabelPresence.CheckNodeLabelPresencePred?=?"CheckNodeLabelPresence"//?CheckServiceAffinityPred?defines?the?name?of?predicate?checkServiceAffinity.CheckServiceAffinityPred?=?"CheckServiceAffinity"//?MaxEBSVolumeCountPred?defines?the?name?of?predicate?MaxEBSVolumeCount.//?DEPRECATED//?All?cloudprovider?specific?predicates?are?deprecated?in?favour?of?MaxCSIVolumeCountPred.MaxEBSVolumeCountPred?=?"MaxEBSVolumeCount"//?MaxGCEPDVolumeCountPred?defines?the?name?of?predicate?MaxGCEPDVolumeCount.//?DEPRECATED//?All?cloudprovider?specific?predicates?are?deprecated?in?favour?of?MaxCSIVolumeCountPred.MaxGCEPDVolumeCountPred?=?"MaxGCEPDVolumeCount"//?MaxAzureDiskVolumeCountPred?defines?the?name?of?predicate?MaxAzureDiskVolumeCount.//?DEPRECATED//?All?cloudprovider?specific?predicates?are?deprecated?in?favour?of?MaxCSIVolumeCountPred.MaxAzureDiskVolumeCountPred?=?"MaxAzureDiskVolumeCount"//?MaxCinderVolumeCountPred?defines?the?name?of?predicate?MaxCinderDiskVolumeCount.//?DEPRECATED//?All?cloudprovider?specific?predicates?are?deprecated?in?favour?of?MaxCSIVolumeCountPred.MaxCinderVolumeCountPred?=?"MaxCinderVolumeCount"//?MaxCSIVolumeCountPred?defines?the?predicate?that?decides?how?many?CSI?volumes?should?be?attached.MaxCSIVolumeCountPred?=?"MaxCSIVolumeCountPred"//?NoVolumeZoneConflictPred?defines?the?name?of?predicate?NoVolumeZoneConflict.NoVolumeZoneConflictPred?=?"NoVolumeZoneConflict"//?EvenPodsSpreadPred?defines?the?name?of?predicate?EvenPodsSpread.EvenPodsSpreadPred?=?"EvenPodsSpread" )

常用的預(yù)選策略：

PodFitsHostPorts：如果 Pod 中定義了 hostPort 屬性，那么需要先檢查這個(gè)指定端口是否已經(jīng)被 Node 上其他服務(wù)占用了。
PodFitsHost：若 pod 對(duì)象擁有 hostname 屬性，則檢查 Node 名稱字符串與此屬性是否匹配。
PodFitsResources：檢查 Node 上是否有足夠的資源（如，cpu 和內(nèi)存）來滿足 pod 的資源請(qǐng)求。
PodMatchNodeSelector：檢查 Node 的標(biāo)簽是否能匹配 Pod 屬性上 Node 的標(biāo)簽值。
NoVolumeZoneConflict：檢測(cè) pod 請(qǐng)求的 Volumes 在 Node 上是否可用，因?yàn)槟承┐鎯?chǔ)卷存在區(qū)域調(diào)度約束。
NoDiskConflict：檢查 Pod 對(duì)象請(qǐng)求的存儲(chǔ)卷在 Node 上是否可用，若不存在沖突則通過檢查。
MaxCSIVolumeCount：檢查 Node 上已經(jīng)掛載的 CSI 存儲(chǔ)卷數(shù)量是否超過了指定的最大值。
CheckNodeMemoryPressure：如果 Node 上報(bào)了內(nèi)存資源壓力過大，而且沒有配置異常，那么 Pod 將不會(huì)被調(diào)度到這個(gè) Node 上。
CheckNodePIDPressure：如果 Node 上報(bào)了 PID 資源壓力過大，而且沒有配置異常，那么 Pod 將不會(huì)被調(diào)度到這個(gè) Node 上。
CheckNodeDiskPressure：如果 Node 上報(bào)了磁盤資源壓力過大（文件系統(tǒng)滿了或者將近滿了），而且配置異常，那么 Pod 將不會(huì)被調(diào)度到這個(gè) Node 上。
CheckNodeCondition：Node 可以上報(bào)其自身的狀態(tài)，如磁盤、網(wǎng)絡(luò)不可用，表明 kubelet 未準(zhǔn)備好運(yùn)行 pod。如果 Node 被設(shè)置成這種狀態(tài)，那么 pod 將不會(huì)被調(diào)度到這個(gè) Node 上。
PodToleratesNodeTaints：檢查 pod 屬性上的 tolerations 能否容忍 Node 的 taints。
CheckVolumeBinding：檢查 Node 上已經(jīng)綁定的和未綁定的 PVCs 能否滿足 Pod 對(duì)象的存儲(chǔ)卷需求。

打分策略如下：

SelectorSpreadPriority：盡量將歸屬于同一個(gè) Service、StatefulSet 或 ReplicaSet 的 Pod 資源分散到不同的 Node 上。
InterPodAffinityPriority：遍歷 Pod 對(duì)象的親和性條目，并將那些能夠匹配到給定 Node 的條目的權(quán)重相加，結(jié)果值越大的 Node 得分越高。
LeastRequestedPriority：空閑資源比例越高的 Node 得分越高。換句話說，Node 上的 Pod 越多，并且資源被占用的越多，那么這個(gè) Node 的得分就會(huì)越少。
MostRequestedPriority：空閑資源比例越低的 Node 得分越高。這個(gè)調(diào)度策略將會(huì)把你所有的工作負(fù)載（Pod）調(diào)度到盡量少的 Node 上。
RequestedToCapacityRatioPriority：為 Node 上每個(gè)資源占用比例設(shè)定得分值，給資源打分函數(shù)在打分時(shí)使用。
BalancedResourceAllocation：優(yōu)選那些使得資源利用率更為均衡的節(jié)點(diǎn)。
NodePreferAvoidPodsPriority：這個(gè)策略將根據(jù) Node 的注解信息中是否含有 scheduler.alpha.kubernetes.io/preferAvoidPods 來計(jì)算其優(yōu)先級(jí)。使用這個(gè)策略可以將兩個(gè)不同 Pod 運(yùn)行在不同的 Node 上。
NodeAffinityPriority：基于 Pod 屬性中 PreferredDuringSchedulingIgnoredDuringExecution 來進(jìn)行 Node 親和性調(diào)度。你可以通過這篇文章 Pods 到 Nodes 的分派來了解到更詳細(xì)的內(nèi)容。
TaintTolerationPriority：基于 Pod 中對(duì)每個(gè) Node 上污點(diǎn)容忍程度進(jìn)行優(yōu)先級(jí)評(píng)估，這個(gè)策略能夠調(diào)整待選 Node 的排名。
ImageLocalityPriority：Node 上已經(jīng)擁有 Pod 需要的容器鏡像的 Node 會(huì)有較高的優(yōu)先級(jí)。
ServiceSpreadingPriority：這個(gè)調(diào)度策略的主要目的是確保將歸屬于同一個(gè) Service 的 Pod 調(diào)度到不同的 Node 上。如果 Node 上沒有歸屬于同一個(gè) Service 的 Pod，這個(gè)策略更傾向于將 Pod 調(diào)度到這類 Node 上。最終的目的：即使在一個(gè) Node 宕機(jī)之后 Service 也具有很強(qiáng)容災(zāi)能力。
CalculateAntiAffinityPriorityMap：這個(gè)策略主要是用來實(shí)現(xiàn)pod反親和。
EqualPriorityMap：將所有的 Node 設(shè)置成相同的權(quán)重為 1。

自定義調(diào)度器

除了 kubernetes 自帶的調(diào)度器，考慮到實(shí)際環(huán)境中的各種復(fù)雜情況，kubernetes 的調(diào)度器采用插件化的形式實(shí)現(xiàn)，可以方便用戶進(jìn)行定制或者二次開發(fā)，我們可以自定義一個(gè)調(diào)度器并以插件形式和 kubernetes 進(jìn)行集成。你也可以編寫自己的調(diào)度器。通過 spec:schedulername 參數(shù)指定調(diào)度器的名字，可以為 pod 選擇某個(gè)調(diào)度器進(jìn)行調(diào)度。

kube-scheduler在啟動(dòng)的時(shí)候可以通過?--policy-config-file參數(shù)來指定調(diào)度策略文件，我們可以根據(jù)我們自己的需要來組裝Predicates和Priority函數(shù)。選擇不同的過濾函數(shù)和優(yōu)先級(jí)函數(shù)、控制優(yōu)先級(jí)函數(shù)的權(quán)重、調(diào)整過濾函數(shù)的順序都會(huì)影響調(diào)度過程。

比如下面的 pod 選擇 test-my-scheduler 進(jìn)行調(diào)度，而不是默認(rèn)的 default-scheduler：

apiVersion:?v1 kind:?Pod metadata:name:?test-schedulerlabels:name:?testscheduler-example spec:schedulername:?test-my-schedulercontainers:-?name:?pod-with-second-annotation-containerimage:?gcr.io/google_containers/pause:2.0

調(diào)度器的編寫請(qǐng)參考 kubernetes 默認(rèn)調(diào)度器的實(shí)現(xiàn)，最核心的內(nèi)容就是讀取 apiserver 中 pod 的值，根據(jù)特定的算法找到合適的 node，然后把調(diào)度結(jié)果會(huì)寫到 apiserver。

官方給出的范例：

#!/bin/bash SERVER='localhost:8001' while?true; dofor?PODNAME?in?$(kubectl?--server?$SERVER?get?pods?-o?json?|?jq?'.items[]?|?select(.spec.schedulerName?==?"my-scheduler")?|?select(.spec.nodeName?==?null)?|?.metadata.name'?|?tr?-d?'"') ;doNODES=($(kubectl?--server?$SERVER?get?nodes?-o?json?|?jq?'.items[].metadata.name'?|?tr?-d?'"'))NUMNODES=${#NODES[@]}CHOSEN=${NODES[$[?$RANDOM?%?$NUMNODES?]]}curl?--header?"Content-Type:application/json"?--request?POST?--data?'{"apiVersion":"v1",?"kind":?"Binding",?"metadata":?{"name":?"'$PODNAME'"},?"target":?{"apiVersion":?"v1",?"kind" :?"Node",?"name":?"'$CHOSEN'"}}'?http://$SERVER/api/v1/namespaces/default/pods/$PODNAME/binding/echo?"Assigned?$PODNAME?to?$CHOSEN"donesleep?1 done

總結(jié)

以上是生活随笔為你收集整理的Kubernetes 是如何调度的？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

kubernetes

上一篇：迈克尔·戴尔再次到访2019戴尔科技峰会
下一篇：建议看 | 计算机网络核心概念