第4章 Kubernetes调度与资源管理：调度策略、资源配额、LimitRange、Node亲和性
本章定位：调度与资源管理是Kubernetes面试中「高频+深挖」的必考模块。面试官通过调度策略考察你对集群资源的掌控力，通过ResourceQuota/LimitRange考察多租户隔离设计能力，通过Node亲和性考察调度精细化程度。本章围绕三大核心考点，拆解回答框架与实战话术。
🎯 面试问题
请解释Kubernetes调度策略：亲和性、反亲和性、Taints/Tolerations的核心区别及适用场景。
🧐 面试官考察点：
- 是否理解调度器Filter+Score两阶段机制
- 能否清晰区分三种策略的作用边界
- 是否有真实项目中的组合使用经验
📐 回答框架： 调度器流程总述 → 三种策略分别定义 → 对比适用场景 → 项目组合示例
✏️ 示例回答：
Kubernetes调度器通过Filter过滤不满足条件的Node，再通过Score打分选出最优Node。亲和性引导Pod到特定Node，反亲和性分散Pod避免单点故障，Taints/Tolerations用于隔离特殊Node（如GPU节点）。实际项目中常组合使用：GPU节点打Taint，通过Tolerations允许训练Pod调度，同时用反亲和性分散Pod避免单卡过热。
🔍 可能追问：
- 硬亲和与软亲和在调度失败时的行为差异是什么？
- 如何实现Pod间反亲和？requiredDuringScheduling与preferredDuringScheduling的区别？
- Taints的NoExecute效果如何影响运行中的Pod？
⚠️ 避坑提醒：不要混淆Node亲和性与Pod亲和性；Taints的NoExecute会驱逐已有Pod，需配合tolerationSeconds控制。面试时避免只背概念，一定要带场景举例。
🎯 面试问题
ResourceQuota和LimitRange在资源管理中有何区别？如何协同工作？
🧐 面试官考察点：
- 是否理解资源管理的分层架构（集群→命名空间→Pod）
- 能否清晰对比两个工具的管控维度
- 是否有多租户资源隔离的实践经验
📐 回答框架： 分别说明作用 → 对比维度（范围/粒度/强制方式） → 协同使用模式 → 场景举例
✏️ 示例回答：
ResourceQuota限制命名空间总资源上限，防止总量超卖；LimitRange设置Pod/容器的默认资源边界，防止单个Pod过度占用。两者配合实现"软硬结合"：Quota设硬上限，LimitRange设默认值+边界。在SaaS多租户场景，先给每个租户命名空间配Quota，再设LimitRange约束单Pod规格。
🔍 可能追问：
- ResourceQuota对PVC、Service等非计算资源如何限制？
- LimitRange的default与defaultRequest有什么区别？
- 如果Pod未指定requests，LimitRange如何生效？
⚠️ 避坑提醒：ResourceQuota不限制已运行的Pod，需提前规划；LimitRange仅对新创建Pod生效。面试时强调"先规划后部署"的思维，避免纸上谈兵。
🎯 面试问题
详细说明Node亲和性（nodeAffinity）的required与preferred类型，以及它们在Pod调度中的实际应用。
🧐 面试官考察点：
- 是否掌握required与preferred的语义差异
- 能否结合权重、拓扑等进阶用法
- 是否有利用亲和性优化调度效率的实战案例
📐 回答框架： 定义Node亲和性 → 区分required/preferred → 权重与运算符说明 → 实际应用场景
✏️ 示例回答：
requiredDuringScheduling硬性要求Node必须满足标签条件，否则Pod无法调度；preferredDuringScheduling软偏好，调度器按权重打分优先满足。实际中用preferred实现流量就近路由，用required将敏感Pod调度到专属Node。配合In/NotIn/Exists运算符可灵活组合标签匹配规则。
🔍 可能追问：
- nodeAffinity与nodeSelector有何异同？
- preferred的weight如何影响调度器打分？
- DuringScheduling与DuringExecution的区别？
⚠️ 避坑提醒：不要忽略required与preferred的"DuringScheduling/DuringExecution"时间维度差异；preferred仅影响调度打分，不保证执行。避免只说概念，一定要结合节点拓扑或硬件调度场景。
🏗️ 项目案例：基于Kubernetes与Volcano的AI训练调度平台
| 业务背景 | 公司AI团队使用GPU进行分布式训练，多团队共享集群，出现资源争抢、GPU利用率低、训练任务排队严重等问题。 |
| 规模指标 | 800台物理Node（含400张V100 GPU），日均调度5000+训练Pod，支持300+数据科学家 |
| 技术栈 | Kubernetes 1.22 · Volcano v1.6 · NVIDIA GPU Share · Custom Metrics · ResourceQuota · LimitRange · NodeAffinity |
| 核心难点 | ① GPU碎片化（不同团队需求GPU数量不一） ② 训练任务优先级混部（紧急训练 vs 常规任务） ③ 多租户资源公平分配 |
🔥 面试高频追问：
- Volcano的Gang Scheduling如何解决多卡训练死锁？
- NodeAffinity在GPU调度中具体怎么配置？
- ResourceQuota如何动态调整？有没有遇到配额碎片问题？
- GPU Share如何实现？与整卡调度相比的优缺点？
💬 可迁移回答话术：
"在AI训练平台项目中，我们组合使用Volcano的Gang Scheduling、NodeAffinity与ResourceQuota：Gang Scheduling解决多卡训练死锁，NodeAffinity将GPU Pod定向调度到GPU节点，ResourceQuota保障多团队公平分配。核心思路是'调度策略与业务优先级对齐'，通过Taints隔离GPU节点，配合Tolerations允许训练Pod调度，同时用Pod反亲和性避免单节点过热。这套组合方案使GPU利用率从32%提升到71%，训练任务排队时间减少65%。"
"在AI训练平台项目中，我们组合使用Volcano的Gang Scheduling、NodeAffinity与ResourceQuota：Gang Scheduling解决多卡训练死锁，NodeAffinity将GPU Pod定向调度到GPU节点，ResourceQuota保障多团队公平分配。核心思路是'调度策略与业务优先级对齐'，通过Taints隔离GPU节点，配合Tolerations允许训练Pod调度，同时用Pod反亲和性避免单节点过热。这套组合方案使GPU利用率从32%提升到71%，训练任务排队时间减少65%。"
📊 调度策略核心对比
| 策略类型 | 作用维度 | 关键字段 | 典型场景 |
|---|---|---|---|
| Node亲和性 | Node标签 | nodeSelector / nodeAffinity | 定向调度到GPU/SSD节点 |
| Pod亲和性 | Pod拓扑 | podAffinity | 将相关Pod部署在同一可用区 |
| Pod反亲和性 | Pod拓扑 | podAntiAffinity | 分散Pod提高可用性 |
| Taints/Tolerations | Node污点 | taints / tolerations | 隔离特殊Node（GPU/专用硬件） |
📊 资源管理工具对比
| 工具 | 作用范围 | 资源类型 | 管控方式 | 生效时机 |
|---|---|---|---|---|
| ResourceQuota | 命名空间 | CPU/内存/PVC/Service | 硬限制（总量上限） | Pod创建时校验 |
| LimitRange | Pod / 容器 | CPU/内存 | 默认值 + 边界约束 | Pod创建时注入/校验 |
| Quota + LimitRange | 命名空间 + Pod | 组合 | 软硬结合（推荐模式） | 创建时双重校验 |