Kubernetes调度器原理深挖：从调度流程到抢占的完整链路

1. 面试官问调度器原理究竟在考什么每次K8s相关的技术面几乎绕不开调度器。我见过很多候选人把K8s组件背得滚瓜烂熟什么Controller Manager负责调和、etcd存数据、API Server是入口但一被追问Pod从创建到运行调度器内部到底经历了什么就开始含糊其辞。面试官爱问这个我觉得很大程度是因为调度器是控制面里唯一一个纯算法纯流程的组件不像其他组件那样依赖具体业务场景非常适合在几十分钟内考察一个人的真实理解深度。ks调度器这个说法其实就是Kubernetes Scheduler在中文社区的常用简称。面试中围绕它的经典问法、连环追问翻来覆去就那几板斧调度流程是什么过滤和打分有多少种策略Pod调度失败会怎样自定义调度器怎么做这些问题听起来不难但想答到点上需要把调度器当作一条完整的数据链来理解而不是背几个名词。这篇文章我按面试的追问逻辑来拆把调度器从watch资源、入队、过滤、打分、绑定到抢占的完整链路讲清楚顺便把我自己面试别人和被别人面试时积累下来的高频坑都列出来。内容稍微有点长但也正因为长你要是能耐心读完而不是只点收藏那才是真学会了。2. 先建立整体认知调度器是一条处理链路不是一台分配机器很多人对调度器有个误解以为它就是看看哪个节点空闲就把Pod扔过去。真实的调度器要比这复杂得多它本质上是一条事件驱动的处理管道。2.1 调度器的三个组成部分拆开来看kube-scheduler这个组件内部可以分成三块事件监听层通过client-go的Informer机制监听API Server上的Pod、Node、PersistentVolume等资源变化。每次有新的待调度Pod出现或者节点状态变化、资源释放Informer都会把这些事件推送过来。调度队列层监听到的新Pod不会立刻进入调度流程而是先放入一个内部队列。队列又区分为activeQ活跃队列、backoffQ退避队列和unschedulableQ不可调度队列。调度失败的Pod会进入unschedulableQ等触发条件满足后重新回到activeQ。调度框架层从activeQ取出一个Pod后依次执行过滤、打分、绑定这一整套插件逻辑。这一层是K8s从1.15版本开始引入的Scheduler Framework也是现在面试考察的重点。很多面试题问调度器怎么保证不重复调度同一个Pod答案就在第一层Informer基于API Server的watch机制加上schedule cache的本地缓存确保调度器对每个Pod的操作有幂等性。而且调度器本身是支持多副本部署的多个副本之间通过etcd上的锁lease机制做选主只有一个leader在真正干活。2.2 调度周期与绑定周期两个容易混淆的阶段调度器内部把一次完整的调度分成两个阶段这是面试特别喜欢抠细节的地方调度周期Scheduling Cycle从队列取出Pod依次执行PreFilter、Filter、PostFilter、PreScore、Score、NormalizeScore这些扩展点最后选出一个最优节点。这个阶段是纯计算不产生任何副作用——Pod还是Pending状态节点没有被占用。绑定周期Binding Cycle在选定的节点上执行Reserve、Permit、PreBind、Bind、PostBind。其中Bind会真正调用API Server的接口把Pod和Node的绑定关系写进etcd。这个阶段是有副作用的Pod从被选中变成被绑定。为什么要分成两个阶段这其实是调度器在性能上做的关键设计。调度周期对同一个Pod只会执行一次但绑定周期可能会因为各种原因失败重试。把纯计算和状态变更分开可以让调度器在失败时不用重新计算节点直接重放绑定逻辑就行。我之前给团队做分享时喜欢打个比方调度周期相当于你在饭店看菜单挑菜挑好了告诉服务员绑定周期相当于后厨真的开始做这道菜。看菜单看一百遍不花钱但菜一旦开始做就得真金白银买单了。2.3 一次完整调度的七步链路把上面两块串起来一次完整的调度长这样Informer监听到一个新Pod且Pod的spec.nodeName为空说明还没被调度。Pod进入调度队列的activeQ按优先级排队。调度器主循环从activeQ取出Pod。执行调度周期过滤候选节点 → 给通过过滤的节点打分 → 选出分数最高的节点。执行绑定周期在选定节点上做资源预留Reserve和绑定Bind。Bind成功后API Server更新Pod对象写入nodeName字段。kubelet监听到Pod被绑定到本节点开始拉镜像、创建容器。面试时能把这条链路完整背出来再补一句Pod真正运行是kubelet的事调度器只负责绑定面试官基本就知道你是真懂了。下一层就开始抠细节。3. 过滤阶段不是选哪个节点而是排除哪些节点过滤阶段Filter是调度周期里的第一个核心动作。它的逻辑很朴素遍历集群里的所有节点把不满足条件的节点一个个排除掉留下的节点才有资格参与打分。如果过滤之后一个节点都没剩下调度就失败了。3.1 常考的过滤插件清单K8s通过插件化的方式实现了二十多个过滤策略面试不能只背插件名得知道每个插件背后的判断逻辑。下面是我整理的几个高频考点。NodeName直接匹配Pod.spec.nodeName这个最基础一般没人会在这里卡住。NodeUnschedulable检查节点是否打了unschedulable标记也就是我们平时执行kubectl cordon后节点会带上的状态。被cordon的节点会被直接过滤掉。NodeResourcesFit这是最核心的资源过滤插件。它检查节点剩余可用资源是否满足Pod的requests。剩余可用资源的计算方式是节点可分配资源 - 已调度的Pod的requests - 为系统组件预留的资源。这里有一个高频坑面试官问节点16G内存怎么算还剩多少很多人忽略kubelet自己会预留一部分给系统进程通过--system-reserved和--kube-reserved参数控制答出来的数字就不对。另外kubelet还支持设置eviction-hard的驱逐阈值比如内存少于100Mi就驱逐Pod这部分区域在资源计算时也被视为不可用。TaintToleration检查Pod是否能容忍节点上的污点。节点有污点Taint而Pod没有对应容忍Toleration这个节点就会被排除。这个插件的细节在于污点有个tolerationSeconds的机制如果Pod的容忍是带时间的表示在这个时间范围内接受调度时间到了就被驱逐。面试问DaemonSet为什么能调度到被打了污点的节点就是因为DaemonSet的Pod默认对node.kubernetes.io/unschedulable这类污点有容忍。NodeAffinity检查节点标签是否满足Pod的节点亲和性要求。分硬性requiredDuringSchedulingIgnoredDuringExecution和软性preferredDuringSchedulingIgnoredDuringExecution两种硬性不满足就直接过滤。InterPodAffinity检查Pod与Pod之间的亲和性和反亲和性。比如要求和DB类型的Pod调度在同一个节点或者不能和前端Pod同节点。这个插件在Filter阶段的逻辑也比较重因为它要根据Pod的标签去匹配集群里其他Pod的分布。PodTopologySpread拓扑分布约束是1.19之后用得越来越多的一个插件。它要求Pod在指定的拓扑域比如region、zone、hostname内尽量均匀分布。Filter阶段做硬性校验比如设置maxSkew1某个节点所在拓扑域当前的Pod数量超出其他域1个以上新Pod就无法调度到这个域。VolumeBinding检查节点是否能满足Pod的存储需求。涉及PV的node affinity、storage class的zone限制、volume是否已被别的节点挂载单节点读写卷的限制。这个插件我见过很多面试者忽略但实际生产里因为存储导致的调度失败其实非常常见。3.2 过滤阶段的面试必答场景面试官最爱问的一个综合场景题是一个节点打了污点、配置了专门的标签、而且快满负荷了一个新Pod能不能调上去这个问题其实考察的就是多个过滤插件如何共同生效。一个稍微完整的回答思路是首先看Pod是否有对应污点的容忍没有就pass。看Pod的nodeSelector/nodeAffinity是否要求该节点的标签如果要求了不匹配的标签也pass。看节点剩余资源够不够Pod的requests不够就pass。如果Pod有拓扑分布约束还要看当前该拓扑域的Pod数量是否已经达到倾斜上限。如果Pod有PVC还得检查这个节点能否满足存储卷的zone和挂载约束。所有条件都满足节点才进入打分池。这里我要特别强调一下过滤阶段有一个批量执行和短路的机制。所有Filter插件会并行跑但一旦某个插件返回不通过当前Pod对这个节点的判断立刻结束剩余插件不再执行。这是调度器的性能优化点面试能提到并行短路机制会显得你对实现有了解。另外Filter阶段缓存了节点的快照信息snapshot不是每次实时查节点状态这也是为什么从节点状态变化到调度感知有一定延迟。4. 打分阶段从一堆合格节点里挑出最合适的那一个过滤留下的节点每个都满足硬性条件接下来要通过打分排序选出最优节点。打分阶段的逻辑不是简单的加减法而是一套可插拔的加权计算体系。4.1 打分插件的核心策略我挑几个面试出现频率最高的打分插件讲。NodeResourcesFit打分模式这是最有意思的一个插件因为它在Filter和Score两个阶段都起作用。打分时它有几个可选的策略LeastAllocated优先选择资源剩余最多的节点适合跑批任务、追求负载均衡的场景。MostAllocated优先选择资源剩余最少的节点适合集群资源本来就紧张、希望尽量打满少数节点的场景。RequestedToCapacityRatio按照用户自定义的资源配比函数打分适用于混合负载场景。默认策略是LeastAllocated。它的计算公式大致是得分基于CPU和内存的利用率利用率越低的节点得分越高。这里有个容易答错的地方打分时是CPU和内存分别算分再取平均不是把两个资源合在一起算。NodeResourcesBalancedAllocation这个插件负责检查节点上CPU和内存的使用率是否均衡。如果一个节点CPU用到80%但内存才用了20%说明存在资源碎片打分会被压低。这个插件在Pod申请多种资源时权重比较高因为它的目标就是让节点上各种资源保持齐步走的消耗节奏。ImageLocality检查节点上是否已经存在Pod要用的镜像。如果镜像已经拉过省去了拉镜像的时间这个节点会得到更高分。生产经验里这个插件对Pod启动速度影响非常明显尤其是几十GB的大型镜像。NodeAffinity打分模式软性节点亲和性在这里生效。用户设置的preferredDuringSchedulingIgnoredDuringExecution规则中每一项有一个权重满足的规则越多加分越多。PodTopologySpread打分模式在Filter阶段保证硬性约束的基础上打分阶段做更细粒度的均匀化。默认参数 in scoring会倾向于选择让Pod分布更均匀的节点。InterPodAffinity打分模式软性的Pod亲和/反亲和规则在Score阶段给符合条件的节点加分。4.2 打分结果是怎么算出来的具体计算过程我拿一个简化例子演示方便你面试时也能推演出来。假设有三个候选节点N1、N2、N3只考虑两个打分插件P1和P2权重分别是1和2。P1给三台节点的原始分是60/70/800-100分P2给的原始分是90/80/70。每个插件的得分是原始分乘以权重然后所有插件的加权得分加总N1: 60×1 90×2 240N2: 70×1 80×2 230N3: 80×1 70×2 220最终N1胜出。真实场景里还需要考虑NormalizeScore这个扩展点。某些插件返回的分数范围不是0-100比如拓扑分布插件可能返回原始数量值NormalizeScore的作用就是把这些不同量纲的值统一到0-100区间再做加权。几乎每个高分回答都会把插件打分 → 加权 → 归一化这三个步骤讲完整。还有一点值得提虽然最终分数最高的节点被选中但调度器在Bind之前还会做一次makeNominatedNode把选中的节点记为候选节点nominated node。这个设计是为了配合抢占调度——一个更高优先级的Pod如果正在抢占节点上的低优先级Pod那么被抢占的Pod在重新调度时可以优先考虑这个候选节点避免频繁换节点。5. 调度框架与插件扩展从能调度到按需调度从K8s 1.15版本开始调度器经历了从硬编码策略到插件化框架的大重构。现在的Scheduler Framework是面试里的高级考点答好了可以直接把面试深度拉高一个档次。5.1 十个扩展点每条链路都有钩子Scheduler Framework定义了一组扩展点Extension Points每个扩展点对应调度过程中的一个阶段。完整的扩展点从上到下依次是QueueSort决定Pod在调度队列中的排序顺序默认按优先级排序。PreFilter对Pod做预处理和前置校验比如检查Pod的请求资源是否符合逻辑可以在预过滤阶段就拦掉明显不合理的Pod。Filter前面讲过的过滤节点逻辑。PostFilter如果Filter之后没有可用节点触发PostFilter最常见的动作就是抢占调度Preemption。PreScore打分前的预操作生成待打分信息比如计算拓扑分布需要的信息。Score给节点打分。NormalizeScore将不同插件的得分统一到相同范围。Reserve在绑定前做资源预留。如果后续绑定失败或发生冲突会执行Unreserve回调释放预留。Permit最后一道审批关卡可以批准、拒绝或延迟绑定。这个扩展点支持外部控制器介入的调度决策。PreBind / Bind / PostBind执行绑定逻辑其中Bind是真正调用API Server写绑定关系的地方。面试官问你想给调度器加一个GPU显存优先分配的规则应该在哪扩展正确答案是通过在Score阶段加一个自定义插件读取GPU显存的请求量和剩余量来影响打分。如果想实现更复杂的逻辑比如显存不够就不能调就应该在Filter阶段拦截。5.2 如何写一个自定义调度插件调度框架的插件接口定义不复杂我写过一个简单的示例核心代码如下type GpuScorePlugin struct { handle framework.Handle } // 插件需要实现Name方法 func (p *GpuScorePlugin) Name() string { return GpuScore } // 在Score阶段给节点打分 func (p *GpuScorePlugin) Score(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeName string) (int64, *framework.Status) { nodeInfo, err : p.handle.SnapshotSharedLister().NodeInfos().Get(nodeName) if err ! nil { return 0, framework.AsStatus(err) } // 取Pod请求的GPU数量 gpuRequest : pod.Spec.Containers[0].Resources.Requests[nvidia.com/gpu] // 取节点已分配的GPU数量不含本Pod gpuAllocated : nodeInfo.Allocatable.ScalarResources[nvidia.com/gpu] - nodeInfo.Requested.ScalarResources[nvidia.com/gpu] // 剩余越多分越高 score : int64(gpuAllocated / gpuRequest * 100) return score, nil }然后在KubeSchedulerConfiguration里通过plugins.score.enabled启用它apiVersion: kubescheduler.config.k8s.io/v1 kind: KubeSchedulerConfiguration profiles: - schedulerName: default-scheduler plugins: score: enabled: - name: GpuScore面试不需要你把代码全部写出来但能讲清楚实现一个接口、注册插件、配置启用这三个步骤然后再举一个实际场景比如GPU调度、网络带宽调度就能非常有力地证明你对调度框架不是纸上谈兵。5.3 多调度器并存生产环境的高级玩法调度框架还天然支持多Profile配置也就是一个kube-scheduler进程里可以配置多个调度器profile。Pod通过spec.schedulerName字段选择使用哪个profile。比如默认调度器处理普通业务Pod另一个profile专门处理批处理Pod走不同的过滤和打分策略。这比部署两套独立的调度器进程更轻量。这个知识点在生产实践里也很常见有些团队会在调度器之上做二次开发比如接入外部资源系统如弹性资源池、专有资源的信息通过扩展点把外部系统的状态纳入调度决策。6. 调度失败与抢占被追问时的破局点如果所有节点都不满足过滤条件会发生什么这是面试官在聊完正常流程后几乎必问的一个问题。答案分两层调度失败的重试机制和抢占调度。6.1 失败重试与节点状态感知过滤阶段全部失败后Pod会带着失败原因进入unschedulableQ。调度器并不会立刻重试而是等待一些可能让Pod调度成功的条件触发把这些Pod重新放回activeQ。触发条件包括有新节点加入集群。有节点状态变化比如从NotReady恢复为Ready。有Pod被删除或调度到别处腾出资源。定时刷新默认每隔一段时间重新尝试。面试要能说出来调度器不是死磕一个Pod而是事件驱动重试 定时兜底。这也是为什么排障时看到Pod一直Pending有时候等几分钟它自己就好了——很可能是等待了一个节点状态变化事件。6.2 抢占调度的完整链路如果Pod设置了高优先级PriorityClass且调度失败就会触发抢占流程。抢占的完整链路值得展开因为它是调度器里最绕的部分调度器先从所有节点里找哪些节点可以容纳高优先级Pod但需要驱逐一些低优先级Pod。对每个候选节点模拟驱逐哪些低优先级Pod之后高优先级Pod能放上去。选出一个受害者最少、且被驱逐的Pod优先级最低的节点。通过DryRun方式正式执行抢占把选中节点上要驱逐的Pod标记为待删除。高优先级Pod被设置为nominatedNodeName等待被驱逐的Pod真正终止后重新进入调度队列完成调度。这里有一个容易被追问的点被抢占的Pod不是立刻消失而是进入优雅终止graceful termination流程。默认宽限期是30秒Pod被标记删除后kubelet会先发SIGTERM给容器等容器优雅退出或超时后才发SIGKILL。只有被驱逐的Pod真正终止后节点资源才会真正释放高优先级Pod才会被调度上去。所以抢占不是瞬间完成的。另外优先级抢占有一个重要约束低优先级Pod被杀死后它本身也会重新排队调度。如果这个低优先级Pod的优先级也不算太低可能会反过来抢占别的Pod形成连环抢占。生产环境里应该尽量避免随意调高Pod优先级否则调度器可能会陷入反复抢占的震荡。6.3 Pending的Pod是否意味着调度器有问题面试还有一个经典问题集群里一堆Pod Pending怎么排查正确的排查顺序是kubectl describe pod看Scheduler Events里的失败原因绝大多数情况失败原因都写得很明确比如0/4 nodes are available: 1 node(s) had untolerated taint, 3 Insufficient cpu。从失败原因反推是过滤阶段的问题资源、污点、亲和性还是打分阶段的问题理论上打分不会导致失败因为打分只是排序。检查调度器自身状态kubectl get lease看leader选举是否正常调度器日志里有没有报错。检查调度队列是否堆积了大量Pod如果集群规模大但调度吞吐不够考虑调度器性能调优。现在新版本的K8s还有一个比较好用的排查手段开启SchedulingFailure事件或者给Pod设置spec.schedulerName指向一个非默认调度器通过调度的日志快速定位问题。7. 高频追问的避坑清单最后这部分我总结一下面试里容易被问住、也容易答偏的细节每条都是我在实战中积累出来的经验。7.1 调度器绑定了PodPod就一定能运行吗不能。调度器完成绑定只是写了nodeName字段。Pod能不能真正运行取决于kubelet是否正常、节点是否有足够的实际资源、镜像能不能拉取、存储卷能不能挂载。面试里比较完整的回答是调度器是决策者kubelet是执行者。决策者只负责说Pod应该去哪执行者才能决定它到底跑不跑得起来。你甚至可以补充一个生产中的真实场景节点内存碎片化严重kubelet在创建Pod的Sandbox时失败Pod一直ContainerCreating而调度器这边已经认为调度成功了。7.2 nodeSelector和nodeAffinity有什么区别nodeSelector是简单的标签精确匹配只能做硬性约束nodeAffinity支持表达式匹配In、NotIn、Exists等还支持软性约束preferred。更进一步nodeAffinity还能与InterPodAffinity配合实现Pod和Pod之间的亲和/反亲和。面试时用一个只能做等值匹配、一个支持表达式且能区分硬约束和软约束来作答就显得很专业。7.3 资源请求是requests还是limits调度时用的是哪个调度只认requests不看limits。这是一个极其常见的误区。limits是cgroup的硬限制在节点实际运行阶段才生效调度阶段只保证Pod的requests能放下。如果一个集群大量Pod设置了很小的requests但limits很大会导致节点上实际负载按limits算远超规格出现节点过载甚至OOM。7.4 多个调度器怎么在集群里共存两个层面一是多个独立的kube-scheduler进程通过--scheduler-name区分二是一个进程内的多Profile。Pod通过schedulerName字段选择。需要补充的是不同调度器互不感知它们都通过同一个APIServer写入绑定关系为了避免冲突调度器在做Bind的时候有版本控制和冲突检测。7.5 调度器本身如何高可用kube-scheduler是多副本部署通过etcd上的coordination.k8s.io/Lease做选主同一时刻只有一个leader在工作其他副本是standby。leader挂了standby会在lease过期后重新选举。这个机制保证了调度器不会出现两个主同时调度的分裂问题。7.6 调度吞吐不够怎么办这属于架构层面的深水区问题。可以从几个方向答调整percentageOfNodesToScore参数默认当集群节点超过100个时分批打分百分比影响调度精度与性能的平衡用kube-scheduler的profiling接口分析插件耗时把一些过重的扩展点逻辑通过外部API异步化或者干脆做水平扩展多副本配合leader选举分摊任务。重点不在于背诵调优参数而是表达了解调度器的性能瓶颈在插件计算和API Server交互上这个认知。我在面试别人时发现能把第6节抢占调度的完整链路和这一节的几个误区都讲清楚的候选人基本可以确定对调度器有真实的工作经验而不是临时背的八股。说句实在话面试官不怕你答不全怕的是你只会背结论、不会顺着问题推演。所以这篇文章的正文部分希望你一句句看下来把调度的整条链路在脑子里过一遍。收藏≠学会这个道理不用我再重复了吧。