调度器与调度策略面试题
本章聚焦 Kubernetes 调度器核心机制、节点选择策略、亲和性/反亲和性配置以及污点与容忍度。面试中常通过“调度全流程模拟”考察底层理解，通过“异常调度排查”考察实战经验。以下先梳理调度流程的关键步骤，再进入高频问答。
面试问答卡片
卡1：调度器整体流程
面试问题：请描述 Kubernetes 调度器将一个 Pod 调度到节点的完整流程。
面试官考察点：是否理解调度器内部架构（scheduler framework）、插件链调用顺序（预选、优选、扩展、绑定）及可扩展点。
回答框架：先总述 Scheduler 通过 informer 监听未调度 Pod → 进入排队队列 → 执行调度 Cycle（预选→优选→预留→批准→绑定）→ 更新 Pod 的 NodeName。强调每个阶段由不同插件完成。
示例回答：“调度器监听 API Server 中 spec.nodeName 为空的 Pod，先经过预选阶段过滤不满足条件的节点，再对剩余节点打分排序，选出最优节点后执行‘保留’防止并发冲突，最后异步绑定到 Etcd，触发 kubelet 创建容器。”
可能追问：“如果调度器挂了，Pod 会一直 pendding 吗？”“抢占式调度如何触发？”
避坑提醒：不要只说“调度器选择一个节点”，要提到调度 framework 的扩展点（如 Filter、Score、NormalizeScore、Bind）。
卡2：节点选择 —— 亲和性与反亲和性
面试问题：nodeSelector、nodeAffinity 和 podAffinity 的区别是什么？什么场景下使用反亲和性？
面试官考察点：是否理解强制/软性约束、拓扑键（topologyKey）的作用，以及实际部署中的高可用/故障隔离设计。
回答框架：区分三种选择方式：nodeSelector 是硬匹配 labels；nodeAffinity 支持 required/ preferred（权重）；podAffinity 依赖已有 Pod labels，配合 topologyKey 实现同一拓扑域调度。反亲和性常用于将同服务的副本分布在不同节点或可用区。
示例回答：“nodeSelector 简单硬性匹配；nodeAffinity 更灵活，可设置 scoring。podAffinity 适用范围是 Pod 间，例如将多个组件调度到同一节点降低延迟，反亲和则用于分散副本，避免单点故障。”
可能追问：“topologyKey 在反亲和中设置成 kubernetes.io/hostname 和 failure-domain.beta.kubernetes.io/zone 有什么不同？”
避坑提醒：“反亲和性”有 required 和 preferred 之分，required 会迫使 Pod 无法调度时保持 Pending，优先用 preferred。
卡3：污点与容忍度
面试问题：污点（Taint）和容忍度（Toleration）如何工作？如何驱逐节点上的所有非容忍 Pod？
面试官考察点：污点效果（NoSchedule、PreferNoSchedule、NoExecute）的区别；NoExecute 的 tolerationSeconds 优雅驱逐逻辑。
回答框架：先说明污点是节点的属性，容忍度是 Pod 的属性。通过匹配 key、effect 和 operator（Equal/Exists）决定是否调度或驱逐。NoExecute 会立即驱逐没有对应容忍度的 Pod，但可设置 tolerationSeconds 延迟驱逐。
示例回答：“节点维护时，打上 effect=NoExecute 的污点，所有不含对应容忍度的 Pod 会被立刻驱逐；若要优雅退出，Pod 设置 tolerationSeconds: 300，则会在 300s 后被驱逐。”
可能追问：“系统级污点（node.kubernetes.io/not-ready）如何处理？”
避坑提醒：不要混淆“容忍度”与“亲和性”——容忍度只决定 Pod 能被调度到有污点的节点，不决定具体调度到哪个节点。
项目案例
项目名称：大规模在线推理集群调度优化
| 业务背景 | 某 AI 平台在线推理服务，Pod 数量 5000+，需按 GPU 型号、网络延迟、Pod 间反亲和性分配，避免推理热点。 |
| 规模指标 | 5000 Pods / 1000 节点（GPU+A100）、每日调度次数 80万+、调度延迟 P99 1.2s |
| 技术栈 | Kubernetes 1.24 + scheduler-plugins + volcano 调度器（gang scheduling）+ Prometheus |
| 核心难点 | ① 多维度过滤（GPU、NUMA、拓扑）；② 避免同模型 Pod 堆积在同一节点；③ 调度器并行回归时的状态一致性问题。 |
| 面试高频追问 | “如何自定义得分插件？” “调度器耗时长如何优化？” “Gang scheduling 如何保证 Pod 组一次调度成功？” |
| 可迁移回答话术 | “面对多约束调度，先使用 filter 插件快速剪枝，再用 score 插件按权重排序；通过 profiling 发现预选阶段瓶颈后，改用 nodecache 分批过滤；自定义 Reserve 插件预留资源防止冲突。” |
💡 提示：本节点题常与“调度器扩展点”关联出综合题。建议自行画一遍 scheduler framework 的流程图，标注每个阶段可注入的自定义插件接口。