上一篇【第63篇】Informer機制——K8s高性能事件驅(qū)動的核心沒有它控制器早累死了下一篇【第65篇】kubelet深度解析——節(jié)點上的全能管家摘要當(dāng)你kubectl apply一個PodAPI Server把它存進(jìn)etcd狀態(tài)是Pending——因為還沒決定放哪個Node。這時候Scheduler出場了。Scheduler的工作像高考閱卷先預(yù)選過濾掉不滿足條件的Node就像先劃分?jǐn)?shù)線再優(yōu)選給剩下的Node打分排名就像按總分排座次最后挑最高分的綁定。這套機制在K8s里叫Scheduling Framework由一串可插拔的擴展點組成。這篇文章講透調(diào)度流程、預(yù)選和優(yōu)選的核心策略以及怎么寫自定義調(diào)度插件比如讓GPU Pod只去有GPU的機器。第026篇我們聊過調(diào)度的婚介所比喻這篇是那個比喻的源碼級展開。一、調(diào)度流程總覽1.1 兩階段預(yù)選 優(yōu)選【Scheduler 調(diào)度一個Pod的全流程】 Pod 創(chuàng)建 → 狀態(tài) Pending (沒Node) │ ▼ ┌────────────────────────────────────────────┐ │ 階段1: 預(yù)選 (Filter / Predicates) │ │ 哪些Node有資格? │ │ ? 資源夠嗎?(CPU/內(nèi)存) │ │ ? 有污點不匹配嗎? │ │ ? 端口沖突嗎? │ │ ? 親和性滿足嗎? │ │ → 過濾出合格Node列表 │ └────────────────────────────────────────────┘ │ 合格列表 ▼ ┌────────────────────────────────────────────┐ │ 階段2: 優(yōu)選 (Score / Priorities) │ │ 合格Node里誰最合適? │ │ ? 哪個Node剩余資源多? │ │ ? 哪個Node上同類Pod少?(打散) │ │ ? 哪個Node離數(shù)據(jù)近? │ │ → 每個Node打0-100分加權(quán)求和 │ └────────────────────────────────────────────┘ │ 最高分Node ▼ ┌────────────────────────────────────────────┐ │ 階段3: 綁定 (Bind) │ │ 寫 Pod.spec.nodeName 選中的Node │ │ → 狀態(tài)變 Boundkubelet接手起容器 │ └────────────────────────────────────────────┘要點預(yù)選是排除法先砍掉不合格優(yōu)選是選拔法在合格里挑最好。如果預(yù)選后一個Node都不剩Pod就一直Pending——這時候就該看調(diào)度失敗事件第069篇Event機制、第084篇排障會講。這個先過濾再打分的思路和高考先過線再排名一模一樣。二、Scheduling Framework2.1 擴展點一覽K8s v1.19的調(diào)度器是插件化的由一串?dāng)U展點組成【Scheduling Framework 擴展點(調(diào)度流水線)】 QueueSort → 決定Pod出隊順序(誰先調(diào)度) │ ▼ PreFilter → 預(yù)選前的準(zhǔn)備工作(預(yù)計算) │ ▼ Filter → ★預(yù)選(核心!) 返回true/false │ (插件: NodeUnschedulable/PodFitsResources/ │ NodeAffinity/TaintToleration/... ) ▼ PostFilter→ 預(yù)選全失敗時的補救(如搶占Preemption) │ ▼ Score → ★優(yōu)選(核心!) 給Node打0-100分 │ (插件: LeastAllocated/NodeAffinity/ │ InterPodAffinity/ImageLocality/... ) ▼ Reserve → 預(yù)留資源(防止并發(fā)調(diào)度搶同一Node) │ ▼ Permit → 允許/拒絕/等待(可延遲綁定) │ ▼ PreBind → 綁定前準(zhǔn)備(如準(zhǔn)備網(wǎng)絡(luò)/卷) │ ▼ Bind → ★真正寫 nodeName │ ▼ PostBind → 綁定后清理2.2 關(guān)鍵插件說明擴展點插件名作用FilterPodFitsResourcesPod資源請求 ≤ Node可分配量FilterNodeUnschedulableNode沒被標(biāo)記為不可調(diào)度FilterTaintTolerationPod能容忍Node的污點FilterNodeAffinity滿足節(jié)點親和性FilterInterPodAffinity滿足Pod間親和/反親和ScoreLeastAllocinated剩余資源多的Node高分ScoreBalancedAllocation資源分配均衡的Node高分ScoreInterPodAffinity滿足親和打散的Node高分ScoreImageLocality已有鏡像的Node高分(省拉取)三、預(yù)選策略詳解3.1 常見的一票否決【預(yù)選 每個Filter都是一票否決】 Node A 資源夠 沒污點 端口不沖突 → 合格 ? Node B 資源不夠 → 直接淘汰 ? (其他條件再好也沒用) 核心預(yù)選條件 ? PodFitsResources: requested CPU/Mem ≤ allocatable ? PodFitsHost: Pod指定了nodeName/nodeSelector要匹配 ? PodFitsHostPorts: Node上該hostPort沒被占 ? NoDiskConflict: 掛載的卷不沖突 ? MatchNodeSelector: 匹配nodeSelector ? CheckServiceAffinity: 滿足Service的親和 ? PodToleratesNodeTaints: 容忍Node污點# 看調(diào)度失敗原因(預(yù)選沒過)kubectl describe pod my-pod# Events:# Warning FailedScheduling 0/3 nodes are available:# 1 node(s) had untolerated taint,# 2 node(s) didnt match PodFitsResources (insufficient cpu)# ↑ 直接告訴你哪個預(yù)選條件掛了四、優(yōu)選策略詳解4.1 打分求和【優(yōu)選 多個Score插件加權(quán)求和】 對每個合格Node每個Score插件給0-100分 Node A: LeastAllocated80, Balanced60, ImageLocality40 Node B: LeastAllocated50, Balanced70, ImageLocality90 加權(quán)求和(有默認(rèn)權(quán)重): Node A 80*w1 60*w2 40*w3 總分X Node B 50*w1 70*w2 90*w3 總分Y 選總分最高的 → 如果并列隨機挑一個(防腦裂)4.2 兩個最常用的優(yōu)選【LeastAllocated vs BalancedAllocation】 LeastAllocated (剩余越多分越高): 目的: 把Pod分散到不同Node避免單Node過載 適合: 一般業(yè)務(wù)追求打散 BalancedAllocation (各資源比例均衡分越高): 目的: 避免CPU用光但內(nèi)存閑著(或反過來) 適合: 混合負(fù)載追求資源利用率均衡 實際是兩者配合先用LeastAllocated打散 再用BalancedAllocation避免資源傾斜五、自定義調(diào)度插件5.1 實戰(zhàn)GPU Pod只去GPU節(jié)點// 自定義Score插件(偽代碼): GPU Pod優(yōu)先調(diào)度到有GPU的NodetypeGPUScorePluginstruct{}func(p*GPUScorePlugin)Score(ctx,cycleState,pod,node)(int64,*Status){nodeHasGPU:node.Labels[accelerator]nvidia-tesla-v100podNeedsGPU:pod.Spec.Resources.Limits[nvidia.com/gpu]0ifpodNeedsGPUnodeHasGPU{return100,nil// 完美匹配滿分}ifpodNeedsGPU!nodeHasGPU{return0,nil// 需要GPU但沒GPU0分(自然被淘汰)}return50,nil// 不需要GPU普通分}// 注冊為Score插件 → 編譯進(jìn)自定義調(diào)度器或用調(diào)度器擴展# 或者用現(xiàn)成的: 直接給GPU Node打污點NodeAffinity# 更簡單不用寫代碼(見第027/028篇)kubectl labelnodegpu-node-1acceleratornvidia-tesla-v100 kubectl taint nodes gpu-node-1gputrue:NoSchedule要點大部分自定義調(diào)度需求其實用NodeAffinityTaint/Toleration就能搞定見第027/028篇不用寫插件。真正需要寫調(diào)度插件的是打分邏輯特殊的場景比如考慮實時電價、考慮數(shù)據(jù)局部性。Scheduling Framework的插件化設(shè)計讓擴展調(diào)度變得整潔——你只實現(xiàn)關(guān)心的擴展點其他用默認(rèn)的。本篇小結(jié)Scheduler用預(yù)選優(yōu)選兩階段給Pod選Node預(yù)選是Filter插件的一票否決資源夠嗎、污點容忍嗎、端口沖突嗎優(yōu)選是Score插件加權(quán)打分剩余資源多、分配均衡、鏡像就近的Node高分最后Bind寫nodeName。這套流程封裝在Scheduling Framework里由QueueSort→Filter→Score→Reserve→Permit→Bind等擴展點串成流水線。簡單調(diào)度需求用AffinityTaint就夠了復(fù)雜打分邏輯才需要寫自定義插件。下篇講kubelet——Node上真正起容器的全能管家。上一篇【第63篇】Informer機制——K8s高性能事件驅(qū)動的核心沒有它控制器早累死了下一篇【第65篇】kubelet深度解析——節(jié)點上的全能管家