本篇內(nèi)容主要講解“Kubernetes調(diào)度器的使用方法”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“Kubernetes調(diào)度器的使用方法”吧!
創(chuàng)新互聯(lián)于2013年開始,先為湘西土家族等服務(wù)建站,湘西土家族等地企業(yè),進行企業(yè)商務(wù)咨詢服務(wù)。為湘西土家族企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
kube-scheduler
是 kubernetes 系統(tǒng)的核心組件之一,主要負責整個集群資源的調(diào)度功能,根據(jù)特定的調(diào)度算法和策略,將 Pod 調(diào)度到最優(yōu)的工作節(jié)點上面去,從而更加合理、更加充分的利用集群的資源,這也是我們選擇使用 kubernetes 一個非常重要的理由。如果一門新的技術(shù)不能幫助企業(yè)節(jié)約成本、提供效率,我相信是很難推進的。
默認情況下,kube-scheduler 提供的默認調(diào)度器能夠滿足我們絕大多數(shù)的要求,我們前面和大家接觸的示例也基本上用的默認的策略,都可以保證我們的 Pod 可以被分配到資源充足的節(jié)點上運行。但是在實際的線上項目中,可能我們自己會比 kubernetes 更加了解我們自己的應(yīng)用,比如我們希望一個 Pod 只能運行在特定的幾個節(jié)點上,或者這幾個節(jié)點只能用來運行特定類型的應(yīng)用,這就需要我們的調(diào)度器能夠可控。
kube-scheduler
是 kubernetes 的調(diào)度器,它的主要作用就是根據(jù)特定的調(diào)度算法和調(diào)度策略將 Pod 調(diào)度到合適的 Node 節(jié)點上去,是一個獨立的二進制程序,啟動之后會一直監(jiān)聽 API Server,獲取到 PodSpec.NodeName 為空的 Pod,對每個 Pod 都會創(chuàng)建一個 binding。
kube-scheduler structrue
這個過程在我們看來好像比較簡單,但在實際的生產(chǎn)環(huán)境中,需要考慮的問題就有很多了:
如何保證全部的節(jié)點調(diào)度的公平性?要知道并不是說有節(jié)點資源配置都是一樣的
如何保證每個節(jié)點都能被分配資源?
集群資源如何能夠被高效利用?
集群資源如何才能被最大化使用?
如何保證 Pod 調(diào)度的性能和效率?
用戶是否可以根據(jù)自己的實際需求定制自己的調(diào)度策略?
考慮到實際環(huán)境中的各種復雜情況,kubernetes 的調(diào)度器采用插件化的形式實現(xiàn),可以方便用戶進行定制或者二次開發(fā),我們可以自定義一個調(diào)度器并以插件形式和 kubernetes 進行集成。
kubernetes 調(diào)度器的源碼位于 kubernetes/pkg/scheduler 中,大體的代碼目錄結(jié)構(gòu)如下所示:(不同的版本目錄結(jié)構(gòu)可能不太一樣)
kubernetes/pkg/scheduler -- scheduler.go //調(diào)度相關(guān)的具體實現(xiàn) |-- algorithm | |-- predicates //節(jié)點篩選策略 | |-- priorities //節(jié)點打分策略 |-- algorithmprovider | |-- defaults //定義默認的調(diào)度器
其中 Scheduler 創(chuàng)建和運行的核心程序,對應(yīng)的代碼在 pkg/scheduler/scheduler.go,如果要查看kube-scheduler
的入口程序,對應(yīng)的代碼在 cmd/kube-scheduler/scheduler.go。
調(diào)度主要分為以下幾個部分:
首先是預選過程,過濾掉不滿足條件的節(jié)點,這個過程稱為Predicates
然后是優(yōu)選過程,對通過的節(jié)點按照優(yōu)先級排序,稱之為Priorities
最后從中選擇優(yōu)先級最高的節(jié)點,如果中間任何一步驟有錯誤,就直接返回錯誤
Predicates
階段首先遍歷全部節(jié)點,過濾掉不滿足條件的節(jié)點,屬于強制性規(guī)則,這一階段輸出的所有滿足要求的 Node 將被記錄并作為第二階段的輸入,如果所有的節(jié)點都不滿足條件,那么 Pod 將會一直處于 Pending 狀態(tài),直到有節(jié)點滿足條件,在這期間調(diào)度器會不斷的重試。
所以我們在部署應(yīng)用的時候,如果發(fā)現(xiàn)有 Pod 一直處于 Pending 狀態(tài),那么就是沒有滿足調(diào)度條件的節(jié)點,這個時候可以去檢查下節(jié)點資源是否可用。
Priorities
階段即再次對節(jié)點進行篩選,如果有多個節(jié)點都滿足條件的話,那么系統(tǒng)會按照節(jié)點的優(yōu)先級(priorites)大小對節(jié)點進行排序,最后選擇優(yōu)先級最高的節(jié)點來部署 Pod 應(yīng)用。
下面是調(diào)度過程的簡單示意圖:
更詳細的流程是這樣的:
首先,客戶端通過 API Server 的 REST API 或者 kubectl 工具創(chuàng)建 Pod 資源
API Server 收到用戶請求后,存儲相關(guān)數(shù)據(jù)到 etcd 數(shù)據(jù)庫中
調(diào)度器監(jiān)聽 API Server 查看為調(diào)度(bind)的 Pod 列表,循環(huán)遍歷地為每個 Pod 嘗試分配節(jié)點,這個分配過程就是我們上面提到的兩個階段:
預選階段(Predicates),過濾節(jié)點,調(diào)度器用一組規(guī)則過濾掉不符合要求的 Node 節(jié)點,比如 Pod 設(shè)置了資源的 request,那么可用資源比 Pod 需要的資源少的主機顯然就會被過濾掉
優(yōu)選階段(Priorities),為節(jié)點的優(yōu)先級打分,將上一階段過濾出來的 Node 列表進行打分,調(diào)度器會考慮一些整體的優(yōu)化策略,比如把 Deployment 控制的多個 Pod 副本分布到不同的主機上,使用最低負載的主機等等策略
經(jīng)過上面的階段過濾后選擇打分最高的 Node 節(jié)點和 Pod 進行 binding 操作,然后將結(jié)果存儲到 etcd 中
最后被選擇出來的 Node 節(jié)點對應(yīng)的 kubelet 去執(zhí)行創(chuàng)建 Pod 的相關(guān)操作
其中Predicates
過濾有一系列的算法可以使用,我們這里簡單列舉幾個:
PodFitsResources:節(jié)點上剩余的資源是否大于 Pod 請求的資源
PodFitsHost:如果 Pod 指定了 NodeName,檢查節(jié)點名稱是否和 NodeName 匹配
PodFitsHostPorts:節(jié)點上已經(jīng)使用的 port 是否和 Pod 申請的 port 沖突
PodSelectorMatches:過濾掉和 Pod 指定的 label 不匹配的節(jié)點
NoDiskConflict:已經(jīng) mount 的 volume 和 Pod 指定的 volume 不沖突,除非它們都是只讀的
CheckNodeDiskPressure:檢查節(jié)點磁盤空間是否符合要求
CheckNodeMemoryPressure:檢查節(jié)點內(nèi)存是否夠用
除了這些過濾算法之外,還有一些其他的算法,更多更詳細的我們可以查看源碼文件:k8s.io/kubernetes/pkg/scheduler/algorithm/predicates/predicates.go。
而Priorities
優(yōu)先級是由一系列鍵值對組成的,鍵是該優(yōu)先級的名稱,值是它的權(quán)重值,同樣,我們這里給大家列舉幾個具有代表性的選項:
LeastRequestedPriority:通過計算 CPU 和內(nèi)存的使用率來決定權(quán)重,使用率越低權(quán)重越高,當然正常肯定也是資源是使用率越低權(quán)重越高,能給別的 Pod 運行的可能性就越大
SelectorSpreadPriority:為了更好的高可用,對同屬于一個 Deployment 或者 RC 下面的多個 Pod 副本,盡量調(diào)度到多個不同的節(jié)點上,當一個 Pod 被調(diào)度的時候,會先去查找該 Pod 對應(yīng)的 controller,然后查看該 controller 下面的已存在的 Pod,運行 Pod 越少的節(jié)點權(quán)重越高
ImageLocalityPriority:就是如果在某個節(jié)點上已經(jīng)有要使用的鏡像節(jié)點了,鏡像總大小值越大,權(quán)重就越高
NodeAffinityPriority:這個就是根據(jù)節(jié)點的親和性來計算一個權(quán)重值,后面我們會詳細講解親和性的使用方法
除了這些策略之外,還有很多其他的策略,同樣我們可以查看源碼文件:k8s.io/kubernetes/pkg/scheduler/algorithm/priorities/ 了解更多信息。每一個優(yōu)先級函數(shù)會返回一個0-10的分數(shù),分數(shù)越高表示節(jié)點越優(yōu),同時每一個函數(shù)也會對應(yīng)一個表示權(quán)重的值。最終主機的得分用以下公式計算得出:
finalScoreNode = (weight1 * priorityFunc1) + (weight2 * priorityFunc2) + … + (weightn * priorityFuncn)
上面就是 kube-scheduler 默認調(diào)度的基本流程,除了使用默認的調(diào)度器之外,我們也可以自定義調(diào)度策略。
kube-scheduler
在啟動的時候可以通過 --policy-config-file
參數(shù)來指定調(diào)度策略文件,我們可以根據(jù)我們自己的需要來組裝Predicates
和Priority
函數(shù)。選擇不同的過濾函數(shù)和優(yōu)先級函數(shù)、控制優(yōu)先級函數(shù)的權(quán)重、調(diào)整過濾函數(shù)的順序都會影響調(diào)度過程。
下面是官方的 Policy 文件示例:
{ "kind" : "Policy", "apiVersion" : "v1", "predicates" : [ {"name" : "PodFitsHostPorts"}, {"name" : "PodFitsResources"}, {"name" : "NoDiskConflict"}, {"name" : "NoVolumeZoneConflict"}, {"name" : "MatchNodeSelector"}, {"name" : "HostName"} ], "priorities" : [ {"name" : "LeastRequestedPriority", "weight" : 1}, {"name" : "BalancedResourceAllocation", "weight" : 1}, {"name" : "ServiceSpreadingPriority", "weight" : 1}, {"name" : "EqualPriority", "weight" : 1} ] }
如果默認的調(diào)度器不滿足要求,還可以部署自定義的調(diào)度器。并且,在整個集群中還可以同時運行多個調(diào)度器實例,通過podSpec.schedulerName
來選擇使用哪一個調(diào)度器(默認使用內(nèi)置的調(diào)度器)。
apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: schedulerName: my-scheduler # 選擇使用自定義調(diào)度器 my-scheduler containers: - name: nginx image: nginx:1.10
要開發(fā)我們自己的調(diào)度器也是比較容易的,比如我們這里的 my-scheduler:
首先需要通過指定的 API 獲取節(jié)點和 Pod
然后選擇phase=Pending
和schedulerName=my-scheduler
的pod
計算每個 Pod 需要放置的位置之后,調(diào)度程序?qū)?chuàng)建一個Binding
對象
然后根據(jù)我們自定義的調(diào)度器的算法計算出最適合的目標節(jié)點
與前面所講的調(diào)度優(yōu)選策略中的優(yōu)先級(Priorities)不同,前面所講的優(yōu)先級指的是節(jié)點優(yōu)先級,而我們這里所說的優(yōu)先級 pod priority 指的是 Pod 的優(yōu)先級,高優(yōu)先級的 Pod 會優(yōu)先被調(diào)度,或者在資源不足低情況犧牲低優(yōu)先級的 Pod,以便于重要的 Pod 能夠得到資源部署。
要定義 Pod 優(yōu)先級,就需要先定義PriorityClass
對象,該對象沒有 Namespace 的限制:
apiVersion: v1 kind: PriorityClass metadata: name: high-priority value: 1000000 globalDefault: false description: "This priority class should be used for XYZ service pods only."
其中:
value
為 32 位整數(shù)的優(yōu)先級,該值越大,優(yōu)先級越高
globalDefault
用于未配置 PriorityClassName 的 Pod,整個集群中應(yīng)該只有一個PriorityClass
將其設(shè)置為 true
然后通過在 Pod 的spec.priorityClassName
中指定已定義的PriorityClass
名稱即可:
apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent priorityClassName: high-priority
另外一個值得注意的是當節(jié)點沒有足夠的資源供調(diào)度器調(diào)度 Pod,導致 Pod 處于 pending 時,搶占(preemption)邏輯就會被觸發(fā)。Preemption
會嘗試從一個節(jié)點刪除低優(yōu)先級的 Pod,從而釋放資源使高優(yōu)先級的 Pod 得到節(jié)點資源進行部署。
現(xiàn)在我們通過下面的圖再去回顧下 kubernetes 的調(diào)度過程是不是就清晰很多了:
到此,相信大家對“Kubernetes調(diào)度器的使用方法”有了更深的了解,不妨來實際操作一番吧!這里是創(chuàng)新互聯(lián)網(wǎng)站,更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢,關(guān)注我們,繼續(xù)學習!
網(wǎng)頁標題:Kubernetes調(diào)度器的使用方法
文章源于:http://muchs.cn/article6/ipgsig.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站設(shè)計公司、手機網(wǎng)站建設(shè)、微信公眾號、定制開發(fā)、網(wǎng)站收錄、網(wǎng)頁設(shè)計公司
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)