📚 课程目录第4章调度与资源管理

调度与资源管理：调度器机制、资源配额、亲和性调度

调度与资源管理是 Kubernetes 集群的核心支柱，直接影响 Pod 部署效率与资源利用率。面试官通常从调度器原理、资源配额控制和调度策略三个维度考察候选人的深度理解与实战能力。本小节提供结构化问答框架与真实项目模板，帮助你在高压面试中快速定位问题、组织回答。

问答卡片一：调度器核心机制

面试问题	Kubernetes 调度器如何工作？请完整描述调度流程。
考察点	调度器整体架构、调度策略、队列与绑定机制；是否理解预选→优选→绑定的核心逻辑。
回答框架	1. 调度器从队列中取 Pod；2. 预选阶段过滤不满足条件的节点；3. 优选阶段对通过节点打分排序；4. 绑定阶段将 Pod 与最优节点关联并更新 API Server。
简短示例回答	调度器监听 Pod 事件，将其加入调度队列。预选阶段运行 predicate 函数过滤节点，优选阶段运行 priority 函数打分最高分节点，最终通过 binding 将 Pod 绑定到节点，并更新 etcd。
可能追问	如何实现自定义调度器？调度队列有哪些类型？如何为不同用户设置调度优先级？
避坑提醒	不要遗漏调度队列的扩展机制（如 priorityClass 排序），也勿忽略抢占调度（Preemption）在高优 Pod 场景的作用。

问答卡片二：资源配额与限制

面试问题	ResourceQuota 和 LimitRange 的区别是什么？各自使用场景有哪些？
考察点	资源管控层次：集群级 vs 命名空间级；总量限制 vs 单个 Pod 限制；如何组合使用避免冲突。
回答框架	1. ResourceQuota 限制命名空间内资源总量（CPU/内存/PVC 数量）；2. LimitRange 为命名空间内每个 Pod/Container 设置默认请求与限制；3. 两者可协同，LimitRange 确保配额不被单个 Pod 耗尽。
简短示例回答	ResourceQuota 设置 namespace 总 CPU 为 10 核、内存 20Gi；LimitRange 设置每个容器默认 request 0.1 核、limit 1 核，避免单个 Pod 占用全部配额。同时使用时需注意 LimitRange 的 default 值应在 quota 范围内。
可能追问	如何为特定 namespace 设置默认资源限制？如果 LimitRange 与 Pod 自身 request 冲突如何处理？
避坑提醒	勿忘记 LimitRange 不适用于所有资源类型（如临时存储需额外配置）；在动态扩缩容场景需验证配额是否溢出导致 Pod 创建失败。

问答卡片三：亲和性调度策略

面试问题	如何利用 Pod 亲和性与反亲和性规则，将相同服务的副本分散到不同节点？
考察点	反亲和性实现原理、拓扑键选择（hostname / zone）、required 与 preferred 的区别。
回答框架	1. 使用 podAntiAffinity 规则；2. 设置 topologyKey 为 kubernetes.io/hostname；3. 选择 requiredDuringSchedulingIgnoredDuringExecution 硬约束或 preferred 软约束；4. 结合 podSelector 匹配 app 标签。
简短示例回答	定义 podAntiAffinity 的 required 规则，labelSelector 匹配 app: my-service，topologyKey 用 hostname。这样每个节点上仅允许运行一个副本，实现故障域分散。若节点数不足，可改用 preferred 软约束。
可能追问	Node 亲和性与 Pod 亲和性的区别？如何同时使用节点与 Pod 亲和性？拓扑键设置为 zone 的适用场景？
避坑提醒	注意 required 硬约束可能导致 Pod 无法调度（节点数不足），建议结合 PodDisruptionBudget 使用；同时避免在滚动更新时反亲和性规则造成旧副本无法被新副本替换。

项目案例：电商业务大促弹性调度与资源管控

项目名称	电商 618 大促弹性调度与资源管控平台
业务背景	大促期间流量突增 10 倍，核心订单服务需快速扩缩容，同时保证关键业务 Pod 优先调度到高性能节点，避免资源争抢导致延迟。
规模指标	集群 5000 节点，最大 Pod 数 10 万+，日变更 3000+ 次。
技术栈	Kubernetes v1.24, Prometheus + HPA, VPA, descheduler, node-problem-detector, Cluster Autoscaler。
核心难点	① 突发流量下 Pod 调度延迟导致扩容来不及；② 多个业务部门共享集群，资源争抢使核心服务无法及时调度；③ 弹性组件自身资源占用造成调度器饥饿。
面试高频追问	如何降低调度延迟？如何设计资源配额策略避免租户间争抢？如何配置节点标签与污点实现优先调度？
可迁移回答话术	“针对调度延迟，我们采用：① 预选阶段减少不必要的 predicate 函数；② 优先使用 nodeSelector 和亲和性减少候选节点数；③ 为关键 Pod 设置 priorityClass 并启用抢占调度。对于资源配额，按部门划分命名空间并设置 ResourceQuota，再通过 LimitRange 限制单 Pod 资源上限，避免个别 Pod 占满配额。通过节点 taint 和 toleration 将核心服务与大内存计算任务隔离。”

💡 结构化面试要点总结：

调度器问题：聚焦预选/优选/绑定流程+队列扩展；

资源配额：区分 ResourceQuota(总量)与 LimitRange(单 Pod)；

亲和性：硬约束 vs 软约束，topologyKey 选择，避免调度死锁；

项目案例：准备好“调度延迟优化”和“多租户资源隔离”两个核心故事线。