最近整理Kubernetes面试题分类汇总系列成了我的固定习惯这已经是第004篇了。这一篇我准备聊一个每次面试都高概率出现、却最容易让候选人露出破绽的方向调度与资源管理。原因很简单很多朋友能把Pod、Deployment、Service背得滚瓜烂熟但一被问到调度器到底怎么决定Pod跑在哪台机器、requests和limits到底管什么就开始含糊。这篇内容既面向正在准备K8s岗位面试的求职者也适合刚入门想搞懂调度原理的开发者。我尽量按面试官的追问节奏来组织把高频考点、容易踩的认知误区、还有现场排障的思路一起拆开讲。1. 调度器工作流程Pod到底是怎么选节点的1.1 kube-scheduler的四个阶段与经典追问调度器这个组件K8s里叫kube-scheduler它的核心任务只有一个为新建的Pod找到一台合适的节点。面试官问这个题基本是看你有没有真正理解调度是一个先过滤再打分的过程而不是简单地找个空闲机器扔进去。完整流程可以拆成四步调度队列排队Pod创建后会进入调度器的队列队列按优先级排序高优先级的Pod可以先被处理。过滤Filtering/预选调度器用一组预选策略把不满足硬性条件的节点剔除。比如节点资源不够、有不能容忍的污点、端口冲突、nodeSelector不匹配这些节点直接出局。打分Scoring/优选剩下的节点进入打分环节调度器根据资源余量、亲和性规则、镜像是否已在节点上等因素给每个节点打分。绑定Binding得分最高的节点胜出调度器把Pod和节点的绑定关系写入etcd之后kubelet才会真正拉镜像、启动容器。面试时我常追问一句调度器挂了集群会怎样很多人第一反应是集群瘫痪其实不对。已运行Pod完全不受影响因为kubelet在本地维护容器运行状态不依赖调度器受影响的只是新建的Pod它们会一直停留在Pending状态。等到调度器恢复队列里的Pod会被继续调度。这个细节很能区分背过文档和真的运维过。还有一个高频追问是调度器本身是不是单点。kube-scheduler可以多副本部署但多个副本之间靠Leader Election选主机制保证同一时刻只有一个调度器在真正干活其他副本处于待命状态。所以它逻辑上是单活物理上是高可用。1.2 亲和性规则千万别只会说有的选亲和性这块面试题往往从怎么让Pod跑到指定节点切入然后一路深入到Pod间亲和与反亲和。先理清三个工具的关系nodeSelector最简单就是精确匹配节点标签比如disktype: ssd。缺点是只能做等值匹配表达力弱。nodeAffinity节点亲和性比nodeSelector强大很多支持In、NotIn、Exists等操作符还分requiredDuringSchedulingIgnoredDuringExecution硬性要求不满足就不调度和preferredDuringSchedulingIgnoredDuringExecution软性偏好不满足也能调度只是打分低。podAffinity / podAntiAffinityPod间的亲和与反亲和解决的问题是哪些Pod要挨在一起或哪些Pod要尽量分开。最常见的一道实战题怎么让一组副本Pod尽量不落在同一台机器上标准做法是给Deployment的Pod模板加一条podAntiAffinityaffinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: app: myapp topologyKey: kubernetes.io/hostname这里的topologyKey是关键它决定了反亲和的范围。用kubernetes.io/hostname表示按节点维度分散意思是尽量别让带有appmyapp标签的Pod出现在同一台节点上。如果集群跨多个可用区想做到可用区级别的高可用就把topologyKey改成topology.kubernetes.io/zone。我的实操经验是这道题值得多说一句为什么用preferred而不是required。required会导致一种尴尬情况如果副本数大于可用节点数多余的Pod永远调度不上去一直Pending。preferred则没有这个风险它是尽量错开实在没位置就挤一挤更适合大多数在线业务。能讲出这层权衡面试官通常会觉得你考虑过生产环境。2. requests与limits背后的资源账本配额、QoS与驱逐顺序2.1 CPU和内存的性格差异一说到资源配额很多同学能背出requests用于调度limits用于限制但面试官真正想听的是为什么CPU和内存处理方式不一样核心原因在于CPU是可压缩资源内存是不可压缩资源。这个性格差异决定了K8s对二者的处理策略完全不同。CPU超卖时节点上的容器只会变慢因为内核通过CFS调度器给各个容器分配CPU时间片大家挤一挤还能跑。内存超卖时就没有商量余地了进程申请不到内存内核只能动用OOM Killer杀掉进程来释放内存。所以K8s对内存的limits执行非常严格一旦容器内存使用超过limits内核会直接杀死容器里的进程这属于cgroup层面的OOM Killed而不是等kubelet来驱逐。这里有个极易被误解的细节requests只影响调度决策不影响运行限制。也就是说你给requests设置2核这个信息只是告诉调度器这台节点至少要有2核空闲才可能调度我但运行时如果你不设limits容器是可以突增使用更多CPU的。反之limits如果不匹配requests就会影响QoS分类进而影响被OOM杀死的优先级。CPU的request/limit单位是核数可以写成500m表示0.5核内存的单位是字节可以写成512Mi、1Gi。写错单位的典型后果是如果你把内存写成2K8s会把它当成2字节而不是2GiB调度器几乎不会因为这2字节拒绝你但容器一启动就会被OOM Kill。这类低级错误在面试题里也出现过值得留意。2.2 QoS分类被OOM Kill的时候谁先死K8s按requests和limits的配置方式把Pod分成三个QoS等级这直接决定了节点内存紧张时的淘汰顺序QoS等级判定条件典型特征Guaranteed每个容器都设置了request和limit且相等最优先保留Burstable至少有一个容器设置了request但不满足Guaranteed系统默认推荐BestEffort所有容器都没设置request和limit最先被淘汰面试常见追问是Guaranteed的Pod就一定不会被OOM Kill吗答案是否定的。OOM Killer的评分机制很复杂不仅看QoS还看进程实际内存占用、CPU使用率等因素。一个Guaranteed容器如果实际内存占用巨大而节点整体又面临内存压力它同样可能被内核选中杀掉。Guaranteed只是降低了被杀概率不是免死金牌。容器被cgroup OOM Kill和Pod被kubelet驱逐是两回事。当容器内存超过自己的limit时是cgroup直接杀掉进程Pod可能显示OOMKilled然后被重启当整个节点内存不足时kubelet会主动驱逐Pod驱逐顺序是BestEffort、Burstable、Guaranteed逐级靠后。这个链条能讲清楚说明你理解K8s的资源管控是分层而非单一机制。2.3 LimitRange与ResourceQuota防止裸奔集群早晚出事如果说requests和limits管的是单个Pod那LimitRange和ResourceQuota管的就是集群范围内的约束这组题在1-3年经验的岗位面试里越来越常见。ResourceQuota作用于Namespace维度限制整个命名空间的资源总和比如CPU总量、内存总量、PVC数量等。LimitRange作用于容器维度可以给Namespace内的容器设置默认的request和limit也可以限制最小值和最大值。一个典型面试场景是你所在团队很多人共用集群总有人忘记写资源请求。怎么保证每个新Pod都有合理的配额标准答案是配LimitRange给该Namespace设置默认值apiVersion: v1 kind: LimitRange metadata: name: default-resource-limit spec: limits: - default: cpu: 500m memory: 512Mi defaultRequest: cpu: 100m memory: 128Mi type: Container这样只要Pod没显式声明资源配额就会被自动补上默认值避免有人无节制地抢占资源导致节点被打爆。ResourceQuota则从总量上兜底防止某个Namespace把整个集群资源耗尽。我实际维护共享集群时这两样几乎是标配面试时能结合这个场景讲比单纯背概念有说服力得多。3. 调度失败现场从Pending到Running的完整排障链路3.1 一眼定位Unschedulable的常见原因调度相关的问题排查是K8s面试中的高发题面试官通常会抛出一个场景有个Pod一直Pending你怎么排查这道题几乎不考记忆力考的就是你有没有在真实环境里处理过问题。最有效的第一步永远是kubectl describe pod pod-name。在Events里会直接出现类似FailedScheduling的事件下面跟着一句0/5 nodes are available的提示然后列出每个节点被过滤的原因。这比看Pod的YAML、看日志都管用因为调度器已经把结论写在事件里了。常见的原因可以分成几类我整理成了排查对照表现象可能原因快速确认方式0/X nodes available全部Insufficient cpu/memory节点资源不足kubectl describe node 查看Allocated resources某个节点提示did not match node selectornodeSelector选不到节点或label不匹配kubectl get nodes --show-labels提示had untolerated taint节点污点没有对应容忍kubectl describe node 查看Taints字段提示node(s) had no available volume zonePVC没绑定或跨可用区挂载受限kubectl describe pvc提示host port already allocated宿主机端口冲突检查hostPort配置和占用情况这里有个我踩过的坑kubectl describe pod里的Events默认只保留最近一小时时间长了事件会被滚动覆盖旧的FailedScheduling信息看不到。所以线上排查要尽快看或者先用kubectl get events --sort-by.metadata.creationTimestamp把集群事件捞出来。3.2 污点与容忍从拒绝到排斥的三级控制污点Taint和容忍Toleration是一个反向筛选机制节点可以嫌弃某些PodPod只有显式声明容忍才能被调度上去。这个机制和亲和性正好互补亲和性是Pod主动挑节点污点是节点主动赶Pod。污点有三个effect这是面试必考NoSchedule不调度新Pod到该节点已运行的Pod不驱逐。PreferNoSchedule尽量不调度是软性约束没有硬性保证。NoExecute新Pod不调度已运行的Pod如果不容忍会被立即驱逐。典型的现实案例是主节点。K8s初始化后master节点默认带一个node-role.kubernetes.io/master:NoSchedule污点所以普通业务Pod不会被调度到master上。如果你想在master上跑一些小工具Pod就得给Pod加对应容忍。面试官常追问NoExecute和节点故障的关系当kubelet检测到节点NotReady比如宕机时它会根据tolerationSeconds决定Pod还能在老节点上待多久。如果Pod容忍了对应污点且声明tolerationSeconds: 60那就等60秒再驱逐如果没容忍会被立刻标记为终止。这背后还涉及节点故障的Pod驱逐由谁处理不是调度器而是节点生命周期控制器在控制面标记节点状态后触发。3.3 优先级、抢占与PodDisruptionBudget高优先级Pod进来时会发生什么再往深一层面试官会问如果所有节点都满了一个高优先级Pod要调度会发生什么这就引出了优先级抢占机制。通过PriorityClass定义优先级高优先级Pod在调度失败时可以去抢占低优先级Pod。调度器会把低优先级Pod驱逐掉腾出资源给高优先级Pod被抢占的Pod根据优雅终止时限被关闭。这个机制听着简单但生产环境里有很大风险如果大量低优先级Pod被频繁驱逐业务稳定性会受影响。于是引出一个配套概念PodDisruptionBudgetPDB。PDB用来限制自愿中断场景下可同时终止的Pod数量比如minAvailable: 2表示自愿驱逐时必须保证至少2个副本存活。但它有个重要边界——只对自愿中断生效比如主动驱逐、升级节点节点宕机这种非自愿中断不受PDB保护。实操中我建议这样配置给核心在线业务Pod加上PDB同时给不同重要程度的负载划分优先级。面试时能把PriorityClass负责抢占排序PDB负责限制影响面这层逻辑讲清楚就说明你真正理解了一组调度策略的配合而不是孤立地背概念。4. 弹性伸缩三兄弟HPA、VPA与节点自动扩缩容4.1 HPA的计算逻辑与为什么会忽大忽小HPAHorizontalPodAutoscaler是面试里最容易问深一层就露馅的话题。很多人能说出HPA根据CPU自动扩容但被问到它到底怎么算的就卡住了。HPA的核心计算公式是期望副本数 ceil(当前副本数 × 当前指标值 / 目标指标值)举个例子当前副本数是3当前CPU平均使用率是80%目标使用率是50%那么期望副本数就是ceil(3 × 80 / 50) ceil(4.8) 5。注意HPA是向上取整哪怕算出来是4.1也会变成5这就是为什么有时候扩容幅度看起来很猛。另一个细节是HPA每15秒拉取一次指标默认--horizontal-pod-autoscaler-sync-period但扩容和缩容都有冷却时间避免指标抖动导致副本数反复横跳。K8s 1.18之后可以通过behavior字段精细控制扩容和缩容的速度比如允许快速扩容、缓慢缩容。指标来源是另一个常见考题。HPA本身不采集数据它依赖Metrics API。CPU和内存这类资源指标来自Metrics Server它通过kubelet的Summary API拿数据并聚合自定义业务指标比如QPS、队列长度则来自Custom Metrics API通常需要外部监控组件适配。4.2 一个真实可用的HPA配置与设置经验我在生产环境写过这样一个HPA同时管两个指标apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: myapp-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: myapp minReplicas: 3 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 - type: Pods pods: metric: name: myapp_requests_per_second target: type: AverageValue averageValue: 200 behavior: scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 10 periodSeconds: 60minReplicas和maxReplicas的设置很有讲究。min设置太小流量突增时扩容需要时间冷启动期间可能直接把服务打垮min设置太大闲时资源浪费严重。我通常建议核心在线服务min设置成能满足日常峰值流量的副本数而不是最低存活数量。max则要结合下游数据库、第三方API的承受能力来定不然扩容太多反而拖垮下游。scaleDown的stabilizationWindowSeconds是另一个容易被忽略的参数它表示缩容前需要等待的稳定窗口。默认值其实是5分钟但如果你的业务流量有周期性波动比如每10分钟一个波峰窗口设太短会导致副本刚缩下来又立刻扩上去白折腾一场。这个参数是我调过最多的地方。4.3 面试加分项HPA、VPA与集群级自动扩缩容的配合能分清HPA、VPA、Cluster Autoscaler三者的分工是区分中级和高级水平的好题目。HPA负责横向扩缩容调整的是Pod副本数不管单个Pod的规格VPAVerticalPodAutoscaler负责纵向扩缩容调整的是Pod的requests和limits让单个Pod“变大变小”Cluster Autoscaler负责节点层面的扩缩容当集群资源不足时自动增加节点资源空闲时回收节点。三者不是互相替代的关系而是配合关系。一个完整的弹性链路是流量上涨触发HPA扩容Pod副本数Pod变多导致节点资源不足Pod调度PendingCluster Autoscaler感知到Pending的Pod后向云厂商API申请增加节点节点就绪后Pod被调度上去。这里提到云厂商的节点池API面试官会对你另眼相看因为这表明你不是只在本地实验环境里玩过而是在公有云环境下处理过真正的扩容。这里有一个常见的坑HPA扩容了但底层节点不够扩容出来的Pod一直Pending服务能力并没有真正提升。所以很多公司会给HPA配一个配套的Cluster Autoscaler同时通过ResourceQuota等机制防止某个业务无限挤占整个集群。能把这条链路讲完整这道题基本就拿下了。5. 面试表达技巧如何把知道答案讲成有深度5.1 用结论-原理-案例三层结构组织答案面试的时候一个人是背题还是真懂往往开口30秒就能分辨出来。我当面试官这些年比较欣赏的回答结构是这样的先给结论一句话说清楚答案再讲原理解释机制背后的逻辑最后给一个自己实际遇到过的案例。三层都有答案就有血有肉。举个例子Pod一直Pending你怎么排查。低分回答是看kubectl describe pod看事件。高分回答是我会先看Pod事件里的FailedScheduling原因定位是资源不足、污点还是亲和性没满足然后根据原因看节点资源分配和标签如果涉及到PVC还要检查存储卷状态。之前我处理过一个案例某服务Pod调度失败的原因是打错了节点标签排查时发现节点本身有GPU资源但label名字写成了gpu-type而不是gpuType导致nodeSelector永远匹配不上。这个回答其实没有用多么高深的技术但它展示了排查路径的完整性和真实经验。面试官想听到的不是教科书而是你在真实环境里解决问题的过程。5.2 三个最容易让候选人翻车的认知误区调度与资源管理这个方向我总结了三个高频认知误区每条都在面试现场见过多次第一个误区设置了limits就一定会被OOM Kill。其实只有内存超过limits会被cgroup杀掉CPU超过limits只会被限流容器还能继续跑。这种混淆往往是因为把limits当成杀死线来理解。第二个误区requests设得越大Pod越安全。requests大确实会让调度器给你预留更多资源但这不代表运行时有保障。requests过大反而会导致节点无法容纳足够多的Pod副本你在资源统计表里看到的已分配资源会快速涨满其他Pod甚至调度不进来。第三个误区Pod打散只需要用podAntiAffinity。反亲和确实能把Pod分散到不同节点但它并不会把Pod分散到不同可用区——除非你正确设置topologyKey。有些同学一套配置用到头节点级分散做到了但可用区级完全没考虑一整个可用区故障就全挂了。面试时说这些误区会有意外的好效果因为它表明你不只知道正确做法还知道为什么很多人会做错这本身就是一种深层理解。5.3 遇到追问卡壳时体面的应对方式面试难免遇到不会的问题调度和资源管理涵盖面很广没人敢说全部精通。关键是怎么应对。我的建议是不要硬答也不要说“这个我没学过”。比较体面的方式是承认自己的知识边界同时立刻给出获取答案的路径HPA对自定义指标的聚合细节我平时接触不多但我了解Metrics API的扩展机制如果给我文档和实际环境我可以快速排查确认。这种回答在面试官眼里比强行编答案要好得多因为它展示了学习能力和解决问题的方法论。另外可以提前准备一个自己亲手做过的资源管理案例比如我在某次大促前发现核心服务扩容到15个副本后命中率下降排查后发现是Pod反亲和配置把副本打散到了同一可用区的多台机器解决了跨可用区问题后性能恢复正常。这种具体的案例很难编造平时没有实际接触过的话很难讲得生动。如果你还没积累这类案例面试前可以自己在实验环境里模拟一下调度失败、资源驱逐的场景把操作命令和事件输出记下来面试时直接讲一遍排障过程效果远超背概念。我个人做了这么多轮技术面试最大的体会是调度与资源管理这块面试官真正在意的不是你能不能背出某个字段的拼写而是你有没有在资源紧张、节点故障、流量突增这些真实场景中亲手处理过问题。如果只能背一组数字我建议把Pod的QoS分类和调度失败时kubectl describe pod的排查命令记牢这比背十道孤立的概念题都管用。下一篇系列我会继续挑一个新的方向来汇总保持这个节奏更新。