Platform Infrastructure

Kubernetes 面试学习

架构主链路 · 调度资源 · Scheduler 内部机制 · Workload Controller · 网络存储 · 安全多租户 · 排障稳定性 · AI Infra GPU/DRA · 扩展与工程化

k8sschedulerworkloadnetworkingstorageoperatorcrdgitopshelmkustomizegpudrainterview

Module Switcher

Kubernetes 面试学习

架构与调度3

Scheduler 插件与扩展1

工作负载与基础设施2

安全与运维2

AI Infra 与扩展3

内容模块

架构与 Pod 主链路

基础★☆☆⏱ 15 min

一句话结论

Kubernetes 是声明式控制系统：API Server 接收期望状态，Controller/Scheduler/kubelet 协同把 Pod 跑起来。

复习定位

维度	内容
所属模块	Kubernetes 核心
章节类型	系统类
解决问题	围绕控制面、调度资源模型、Workload Controller、网络存储、安全多租户、排障和 AI Infra GPU/DRA 建立平台面试答案。
面试抓手	按 API Server、etcd、scheduler、kubelet、container runtime 链路讲。

Kubernetes 架构图

Kubernetes 官方文档组件图：控制面通过 API Server 协调集群状态，节点侧由 kubelet、kube-proxy 和容器运行时执行工作负载。

同一架构的另一视角：CLUSTER 内 Control Plane（cloud-controller-manager / kube-api-server / etcd / scheduler / controller-manager）与多个 Node（kubelet + kube-proxy + CRI 内的 Pod）的归属关系，cloud-controller-manager 单独对接 Cloud Provider API。

一个 Pod 从提交到运行的完整链路

阶段	核心组件	发生什么	面试关键词
提交请求	kubectl / client-go → API Server	用户提交 Pod、Deployment、Job 等资源对象	REST API、OpenAPI、版本转换
认证鉴权	API Server	检查调用者是谁、有没有权限、是否满足准入策略	Authentication、Authorization、Admission
持久化	API Server → etcd	合法对象被写入 etcd，成为集群期望状态	声明式 API、resourceVersion、watch
控制器处理	Controller Manager	Deployment 创建 ReplicaSet，ReplicaSet 创建 Pod	Reconcile、OwnerReference、Finalizer
调度决策	kube-scheduler	监听未绑定 Pod，经过 Filter / Score / Reserve / Bind 选择节点	Scheduling Framework、requests、亲和性、污点容忍
节点执行	kubelet	目标节点 kubelet watch 到 Pod，准备 volume、网络、容器	Pod Worker、PLEG、CNI、CSI、CRI
运行容器	containerd / CRI-O	拉镜像、创建 sandbox、启动容器并持续上报状态	Pause 容器、Pod IP、探针、状态回写

回答结构：Pod 是怎么跑起来的？

可以按“四段式”回答，主线是：所有控制面和节点组件都围绕 API Server 协作，etcd 只负责保存状态，真正执行发生在目标节点的 kubelet 上。

入口：用户通过 kubectl 或 client-go 把 YAML 提交到 API Server。API Server 负责认证、鉴权、准入控制、对象校验和默认值填充；合法对象会通过 API Server 持久化到 etcd。这里要强调：通常只有 API Server 直接读写 etcd，其他组件通过 API Server watch 和更新对象。
控制：如果提交的是 Deployment，Deployment Controller 会 watch API Server 中的对象变化，创建或维护 ReplicaSet；ReplicaSet Controller 再根据期望副本数创建、删除或修复 Pod。这个阶段体现的是 Kubernetes 的声明式 reconcile：用户写期望状态，controller 持续把实际状态逼近期望状态。
调度：scheduler watch 到未调度、未绑定节点的 Pod 后，经过 Filter、Score、Reserve、Permit、Bind 等流程选择合适 Node。调度器不会直接通知 kubelet，而是把绑定结果写回 API Server，例如设置 Pod 的 spec.nodeName 或创建 Binding。后续 kubelet 是通过 watch API Server 才知道这个 Pod 归自己执行。
执行：目标节点上的 kubelet watch 到绑定到本节点的 Pod 后，进入 Pod 生命周期执行流程：先准备 volume（CSI）、创建 Pod sandbox，再由网络插件（CNI）配置 Pod 网络，随后通过 CRI 调用 containerd / CRI-O 拉镜像、创建并启动业务容器。容器启动后，kubelet 继续执行探针、重启策略、资源状态采集，并把 Pod phase、container status、Node status 等状态回写到 API Server。

一句话总结：用户提交期望状态到 API Server，controller 负责创建和维护 Pod，scheduler 负责选 Node 并写回绑定结果，kubelet 在目标节点通过 CSI/CNI/CRI 把 Pod 真正跑起来，并持续向 API Server 上报状态。

追问时可以展开：etcd 一致性与 watch、Informer 缓存机制、scheduler 插件链路、绑定与抢占、kubelet Pod Worker、CSI/CNI/CRI 边界、探针和容器运行时。

控制面与数据面组件速记

组件	职责	常见追问
API Server	所有资源操作入口，负责认证、鉴权、准入、聚合 API、watch	为什么它是唯一直接访问 etcd 的组件？
etcd	保存集群期望状态和关键元数据	备份恢复、watch、resourceVersion、压缩与碎片整理
Scheduler	为未绑定 Pod 选择节点	Filter / Score / Reserve / Permit / Bind 的区别
Controller Manager	运行 Deployment、ReplicaSet、Node、Job 等控制循环	什么是 reconcile？如何处理最终一致性？
kubelet	节点代理，负责 Pod 生命周期和状态上报	kubelet 如何调用 CRI / CNI / CSI？
kube-proxy / eBPF datapath	实现 Service 转发或服务负载均衡	iptables、IPVS、eBPF 的差异
Container Runtime	真正创建和管理容器	CRI、containerd、pause 容器、镜像拉取

控制面与数据面组件高频追问

组件	面试官问法	回答抓手
API Server	为什么它是唯一直接访问 etcd 的组件？	统一认证鉴权、准入、版本转换、乐观并发和 watch 分发；其他组件通过 API Server 解耦。
etcd	resourceVersion 和 watch 有什么关系？	resourceVersion 是对象版本和 watch 起点；watch 太旧会遇到 compacted，需要重新 list。
Scheduler	Filter / Score / Reserve / Permit / Bind 怎么区分？	Filter 判断能不能放，Score 判断放哪里更好，Reserve 本地预留，Permit 等待或拒绝，Bind 写回 API Server。
Controller Manager	什么是 reconcile？	比较期望状态和实际状态，持续创建、更新、删除对象，让系统最终一致。
kubelet	kubelet 如何调用 CRI / CNI / CSI？	CRI 管容器运行时，CNI 配 Pod 网络，CSI / volume manager 挂载存储；kubelet 编排本节点执行。
containerd	containerd、runc、shim、pause 容器分别是什么？	containerd 是高层 runtime，runc 创建 OCI 容器，shim 托管容器进程，pause 持有 Pod 共享 namespace。

Container Runtime / containerd 面试速查

containerd 相关问题通常不是问“会不会用 Docker”，而是问清 kubelet → CRI → containerd → shim → runc 这条节点侧执行链路，以及 Pod sandbox / pause 容器为什么存在。

问题	一句话答案	排障关键词
CRI 是什么？	Kubernetes 定义的容器运行时接口，kubelet 通过 CRI gRPC 调用运行时。	`crictl`、runtime endpoint
containerd 和 runc 区别？	containerd 管镜像、快照、容器生命周期；runc 是 OCI low-level runtime，真正创建 Linux 容器。	OCI bundle、snapshotter
pause 容器是什么？	Pod sandbox 的基础容器，先启动并持有 Pod 的 network / IPC 等共享 namespace。	Pod IP、sandbox
containerd-shim 做什么？	托管容器进程，转发 stdio / exit status，让 containerd 重启后容器仍可继续运行。	shim 进程、僵尸进程
镜像怎么拉？	kubelet 通过 CRI 调 PullImage，containerd 解析 manifest、拉 layer、校验 digest、写入 content store。	ImagePullBackOff、registry、Secret
CNI 谁调用？	kubelet 创建 Pod sandbox 时通过 CRI 触发 runtime 侧配置网络；containerd CRI plugin 会调用 CNI 插件。	ContainerCreating、CNI config
Docker 镜像还能跑吗？	能。移除 dockershim 不等于不能跑 Docker 构建的镜像；镜像遵循 OCI/Docker image spec。	dockershim removed、OCI

架构与 Pod 主链路高频问答

本模块的问答按“概念 → 作用 → 链路/排查 → 面试口径”组织，避免只背一段结论。

Q: API Server 为什么通常是唯一直接访问 etcd 的组件？

因为 API Server 是 Kubernetes 的统一状态入口。它集中处理认证、鉴权、准入、默认值、版本转换、对象校验、乐观并发和 watch 分发。如果 controller、scheduler、kubelet 都直接读写 etcd，权限、版本兼容、并发控制和审计都会失控。

面试口径：etcd 是状态存储，不是组件协作总线；组件协作通过 API Server 和 watch 完成。

Q: Controller Manager 的 reconcile 到底是什么意思？

reconcile 是控制器把实际状态拉回期望状态的循环。以 Deployment 为例，用户声明 replicas=3，Deployment Controller 确保 ReplicaSet 存在，ReplicaSet Controller 确保有 3 个 Pod。Pod 被删、节点故障、状态变化时，controller 会再次对比 spec 和 status，并执行修正动作。

面试口径：reconcile = watch 变化 + 对比期望/实际 + 幂等修正，目标是最终一致，不是同步阻塞执行。

Q: kubelet 如何调用 CRI / CNI / CSI？

kubelet watch 到绑定到本节点的 Pod 后，进入 SyncPod。它先通过 volume manager / CSI 准备卷，再通过 CRI 调用 containerd 创建 Pod sandbox。创建 sandbox 时 runtime 侧会调用 CNI 配置网络，随后 kubelet 继续通过 CRI 拉镜像、创建并启动业务容器。

kubelet
  → CSI / volume manager 准备 volume
  → CRI RunPodSandbox
  → containerd CRI plugin 调 CNI 配网络
  → CRI PullImage / CreateContainer / StartContainer
  → containerd-shim / runc 创建容器进程

面试口径：kubelet 是节点编排者；CRI 管容器，CNI 管网络，CSI 管存储。

Q: containerd、runc、containerd-shim 分别负责什么？

containerd 是高层容器运行时，负责镜像拉取、content store、snapshot、容器生命周期和 CRI 服务。runc 是 OCI low-level runtime，负责根据 OCI spec 真正创建 Linux 容器。containerd-shim 位于 containerd 和容器进程之间，托管容器进程、收集退出状态和 stdio，让 containerd daemon 重启时容器不必一起退出。

面试口径：containerd 管生命周期和镜像，runc 负责创建容器，shim 负责把容器进程和 containerd 解耦。

Q: pause 容器 / Pod sandbox 是什么？为什么需要它？

Pod 不是单个容器，而是一组共享网络等 namespace 的容器。pause 容器是 Pod sandbox 的基础容器，它先启动，持有 Pod 的 network namespace、Pod IP 和部分共享 namespace。业务容器启动时加入这个 sandbox。这样业务容器重启时，Pod 的网络身份可以保持稳定。

面试口径：pause 容器是 Pod 的 namespace 锚点；它让 Pod 里的多个容器共享同一个网络身份。

Q: ImagePullBackOff 和 ErrImagePull 怎么排查？

先看 Pod Events 里的具体错误：镜像名/tag 是否存在、registry 是否可达、imagePullSecret 是否正确、节点 DNS/代理是否正常、证书是否可信。再到节点侧用 crictl pull 或查看 containerd 日志确认 runtime 能否拉取。

kubectl describe pod <pod>
kubectl get secret -n <ns>
crictl pull <image>
journalctl -u containerd

面试口径：ImagePullBackOff 是 kubelet 拉镜像失败后的退避状态；根因通常在镜像名、权限、网络、证书或 registry。

Q: ContainerCreating 卡住通常看哪里？

ContainerCreating 表示已经调度到节点，但节点侧执行还没完成。排查顺序是：Pod Events → kubelet 日志 → containerd 日志 → CNI 日志 / 配置 → CSI mount → 镜像拉取。常见原因包括 CNI 分配 IP 失败、CSI 挂载超时、sandbox 创建失败、镜像拉取慢、节点磁盘压力。

面试口径：Pending 偏调度侧，ContainerCreating 偏节点执行侧；重点看 kubelet、runtime、CNI、CSI。

Q: Kubernetes 移除 dockershim 后，Docker 镜像还能跑吗？

能。dockershim 移除的是 kubelet 直接对接 Docker Engine 的内置适配层，不是移除 Docker 镜像格式。只要镜像符合 OCI / Docker image spec，containerd 和 CRI-O 都可以拉取和运行。变化在节点运行时链路：kubelet 通过 CRI 直接对接 containerd，而不是 kubelet → dockershim → Docker Engine。

面试口径：dockershim removed 不等于 Docker image 不能用；镜像格式兼容，运行时链路变了。

Q: 为什么说 Kubernetes 是声明式系统？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 概念

声明式系统的核心是用户提交“期望状态”，例如 Deployment 期望 3 个副本，而不是一步步命令系统创建哪几个容器。

2. 作用

声明式 API 让系统可以容错和自愈：Pod 被删、节点故障、实际副本数不匹配时，controller 会重新 reconcile。

3. 实现方式

API Server 保存 spec，controller 通过 Informer watch 对象变化，比较期望状态和实际状态，再创建、更新或删除相关对象。

4. 面试边界

etcd 保存状态，API Server 提供读写入口，controller 负责逼近期望状态；不要把 Kubernetes 理解成一次性脚本执行器。

面试口径：Kubernetes 的声明式体现在“用户写 spec，controller 持续 reconcile，最终让实际状态逼近期望状态”。

Q: API Server、Controller、Scheduler、kubelet 都在 watch 什么？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. API Server 的位置

API Server 不只是被 watch 的对象入口，也是认证、鉴权、准入、版本转换和 watch 分发中心，其他组件基本都围绕它协作。

2. Controller watch 什么

Controller watch 自己关心的资源，例如 Deployment、ReplicaSet、Pod、Node，并根据 spec/status 差异执行 reconcile。

3. Scheduler watch 什么

Scheduler 主要 watch 未绑定节点的 Pod，以及 Node、PVC、ResourceClaim 等会影响调度结果的对象。

4. kubelet watch 什么

kubelet watch 绑定到本节点的 Pod，然后在节点侧准备 volume、网络和容器，并持续回写 Pod/Node 状态。

面试口径：watch 机制让组件通过 API Server 解耦协作，Controller 管期望状态，Scheduler 管放置决策，kubelet 管节点执行。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

内容模块

调度与资源模型

进阶★☆☆⏱ 18 min

一句话结论

K8S 调度的核心是 requests/limits、QoS、过滤打分、抢占和扩展资源模型。

复习定位

维度	内容
所属模块	Kubernetes 核心
章节类型	系统类
解决问题	围绕控制面、调度资源模型、Workload Controller、网络存储、安全多租户、排障和 AI Infra GPU/DRA 建立平台面试答案。
面试抓手	AI Infra 场景要补 GPU extended resource 和 device plugin。

调度与资源模型：回答“为什么 Pending”的核心模块

调度和资源模型要一起学。资源模型定义 Pod 要什么、Node 有什么；调度器决定这个 Pod 放到哪里。面试中最常见的追问是：Pod 为什么 Pending、requests/limits 如何影响调度、QoS 如何影响驱逐、GPU 这类扩展资源如何被调度。

先看这张地图

层次	你要回答的问题	典型字段 / 机制	出问题时的现象
资源需求	Pod 需要多少 CPU、内存、GPU、PVC	`requests`、`limits`、Extended Resource、ResourceClaim	`Insufficient cpu/memory/nvidia.com/gpu`
放置约束	Pod 允许放到哪些节点、应该靠近或远离谁	`nodeSelector`、NodeAffinity、PodAffinity、Taint/Toleration、TopologySpread	节点很多但都被 affinity/taint 过滤
节点库存	Node 真正还有多少可分配资源和设备	Node `allocatable`、Device Plugin、DaemonSet 占用、系统预留	看似 8 卡机器，实际 allocatable 不足或设备不可用
调度执行	scheduler 如何用上述信息做过滤和打分	Filter、Score、Reserve、Bind	Pending 事件里出现具体 plugin 失败原因

阅读顺序建议：

先理解 requests/limits：这是 Pod 资源声明和调度判断入口。
再理解 QoS：它是由 CPU/Memory requests/limits 推导出的驱逐等级，不是调度资源本身。
再理解放置约束速览，解释“资源够但为什么不能放”。
GPU / DRA / Affinity 的深入实现不要在本页展开，分别转到对应专题。
最后再进入 Scheduler 主链路 和 Scheduler 插件与扩展，理解这些约束在 Framework 中挂到哪个扩展点。

本页边界：只讲资源模型，不讲插件实现

本页回答 Pod 要什么、Node 有什么、哪些约束会让节点不可用。Scheduler Framework 的内部队列、cache、assume、binding cycle 放在「Scheduler 主链路」；自定义 Plugin、Extender、QueueingHint、可观测性放在「Scheduler 插件与扩展」。

问题类型	应该看哪里
requests/limits、QoS、资源需求和放置约束总览	本页：调度与资源模型
Extended Resource、Device Plugin、DRA、MIG/MPS	AI Infra：GPU / 批调度 / DRA
NodeAffinity、PodAffinity、TaintToleration 的插件行为	Scheduler 插件与扩展 → 设计理念与经典插件
ActiveQ/BackoffQ/UnschedulableQ、Assume、Preemption	Scheduler 主链路
PreFilter/Filter/Score、QueueingHint、Extender、自定义插件	Scheduler 插件与扩展
Gang、Backfill、抢占代价、队列公平	任务调度理论

Resource Requests / Limits：资源声明与运行时上限

requests 和 limits 是 Pod / Container 的资源声明。它们首先回答的是：调度时预留多少资源，运行时最多允许用多少资源。

概念	影响范围	关键结论	常见误区
`requests`	调度、资源预留、HPA 部分指标	scheduler 主要根据 requests 判断节点是否放得下	不是实时使用量；Pod 用得少也会按 request 占调度容量
`limits`	运行时限制	CPU limit 可能 throttling，内存超过 limit 通常 OOMKilled	limits 不是调度依据；内存 limit 过低会直接影响稳定性

面试口径：调度看 requests，不是看实时使用量；limits 主要管运行时上限，CPU 超限是 throttling，内存超限通常是 OOMKilled。

QoS：由 requests / limits 推导出的驱逐等级

QoS 不是一个用户随便填写的字段，而是 kubelet 根据 CPU / Memory 的 requests 和 limits 推导出的等级。它主要影响节点资源压力下的驱逐优先级，而不是决定调度器能不能把 Pod 放到节点上。

QoS 等级	判定条件	驱逐倾向	典型场景
Guaranteed	每个容器 CPU/Memory requests 等于 limits 且都设置	驱逐优先级最低	核心在线服务、强 SLO 服务
Burstable	至少设置了一个 CPU/Memory request，但不完全满足 Guaranteed	中等驱逐优先级	大多数普通服务
BestEffort	没有设置 CPU/Memory requests 和 limits	最先被驱逐	临时任务、低优实验、开发测试

面试口径：QoS 看的是 CPU/Memory requests/limits 组合；驱逐还会结合 PriorityClass、资源压力和实际使用量。

Requests / Limits 与 QoS 的关系

问题	看什么	一句话
Pod 能不能调度到某个节点？	Pod requests vs Node allocatable	调度阶段主要看 requests
容器运行中最多能用多少？	limits	运行时由 cgroup / runtime 限制
节点压力下谁先被赶走？	QoS + PriorityClass + 实际资源压力	QoS 是驱逐排序的重要输入
GPU request/limit 怎么理解？	Extended Resource	普通 GPU 扩展资源通常 requests = limits，按整数设备调度

收束：requests/limits 是输入字段，QoS 是推导结果；调度主要看 requests，驱逐主要看 QoS、优先级和资源压力。

放置约束速览：资源够也可能 Pending

本页只保留调度资源模型视角：Pod 除了要资源，还会声明“能去哪里、应该靠近谁、要不要均匀分布、能不能容忍节点排斥”。这些约束最终会映射到 scheduler 的 Filter / Score 插件。

机制	解决什么问题	深入位置
nodeSelector / Node Affinity	Pod 选择什么样的节点，例如 GPU 型号、机房、磁盘类型	Scheduler 插件与扩展 → 设计理念与经典插件
Pod Affinity / Anti-Affinity	Pod 和已有 Pod 靠近或远离，例如靠近 cache、分散同服务副本	Scheduler 插件与扩展 → 设计理念与经典插件
Topology Spread Constraints	控制副本在 zone、node、rack 等拓扑域内均匀分布	本页保留核心语义
Taint / Toleration	节点拒绝普通 Pod，Pod 显式声明自己能容忍	本页保留核心语义；插件行为见经典插件

本页记入口即可：资源不足看 requests/allocatable；资源够但不能放，通常看 Affinity、Taint、Topology Spread、PVC/ResourceClaim 和自定义插件。

Topology Spread Constraints

Topology Spread Constraints 控制 Pod 在拓扑域（可用区、节点、机架等）上的均匀分布程度。它比 Pod Anti-Affinity 更灵活，可以表达"每个可用区的 Pod 数量差距不超过 1"这类需求。

字段	含义	示例
topologyKey	拓扑域的标签键	`topology.kubernetes.io/zone`（可用区）、`kubernetes.io/hostname`（节点）
maxSkew	允许的最大不均衡度	maxSkew=1 表示各拓扑域 Pod 数量最多差 1
whenUnsatisfiable	无法满足时的行为	DoNotSchedule（硬约束）或 ScheduleAnyway（软约束）
labelSelector	参与计算的 Pod 范围	只统计同 Service 的 Pod

与 Pod Anti-Affinity 的区别

Anti-Affinity 是"每对 Pod 不能在一起"，约束数量随 Pod 数量平方增长。
Topology Spread 是"每个域的 Pod 数量差距不超过 N"，约束数量与域数量相关，更适合大规模均匀分布。

常见坑

如果某个拓扑域没有匹配的节点，DoNotSchedule 会导致 Pod 无法调度。
多个 Spread Constraints 可能互相冲突，导致没有节点满足所有约束。
滚动更新时，新旧 Pod 同时存在可能导致 skew 暂时超标。

Taints & Tolerations

Taint 是打在节点上的"排斥标记"，Toleration 是 Pod 的"容忍声明"。只有 Pod 容忍了节点的所有 Taint，才能被调度到该节点。这是 Kubernetes 中最常用的节点隔离机制。

Effect	行为	典型场景
NoSchedule	不容忍的 Pod 不会被调度到该节点	GPU 节点只跑 GPU Pod、专用节点池
PreferNoSchedule	尽量不调度，但不强制	软性隔离，优先使用其他节点
NoExecute	不容忍的 Pod 会被驱逐（已在运行的也会被赶走）	节点故障预隔离、维护前驱逐

与 nodeSelector / Affinity 的区别

nodeSelector / Affinity 是 Pod "选择"节点（拉模型），Taint 是节点"拒绝" Pod（推模型）。
两者配合使用：Taint 防止无关 Pod 调度到 GPU 节点，nodeSelector 让 GPU Pod 找到 GPU 节点。
生产最佳实践：GPU 节点同时打 Taint + 标签，GPU Pod 同时配 Toleration + nodeSelector。

自动 Taint

kubelet 会在节点异常时自动打 Taint：node.kubernetes.io/not-ready、node.kubernetes.io/unreachable、node.kubernetes.io/out-of-disk、node.kubernetes.io/memory-pressure 等。这些 Taint 的 Effect 是 NoExecute，会导致不容忍的 Pod 被驱逐。

调度与资源模型高频问答

本模块的问答按“概念 → 作用 → 链路/排查 → 面试口径”组织，避免只背一段结论。

Q: Pod Pending 时，调度侧怎么排查？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 先看事件

先用 kubectl describe pod 看 Events，确认是否是 FailedScheduling，不要一上来就猜 kubelet 或 CNI。

2. 资源类原因

对比 Pod requests 和 Node allocatable，关注 CPU、内存、GPU 扩展资源、DaemonSet 占用、系统预留和资源碎片。

3. 约束类原因

检查 nodeSelector、nodeAffinity、podAffinity/anti-affinity、topologySpreadConstraints、taints/tolerations 是否让可选节点变少。

4. 外部依赖原因

如果事件提到 PVC、ResourceClaim、Quota 或队列准入，就分别转到存储、DRA、ResourceQuota、Kueue/Volcano 链路排查。

面试口径：Pending 先看 Events，再按资源、约束、存储、配额、GPU/DRA、调度器插件逐层排查。

Q: requests 和 limits 有什么区别？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. requests 的概念

requests 是 Pod 对资源的最低需求和调度依据，scheduler 用它判断节点是否放得下。

2. limits 的概念

limits 是运行时上限，CPU 超过 limit 通常被 throttling，内存超过 limit 通常触发 OOMKilled。

3. 对 QoS 的作用

CPU/Memory 的 requests 和 limits 组合决定 QoS：Guaranteed、Burstable、BestEffort，进而影响节点压力下的驱逐顺序。

4. 常见误区

调度器默认不看实时使用量，而是看 requests；limits 不是资源预留，设置过低会影响稳定性。

面试口径：requests 主要管调度和预留，limits 主要管运行时限制，QoS 决定资源压力下谁更容易被驱逐。

Q: 为什么 GPU requests 和 limits 通常要相等？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. GPU 的资源属性

GPU 是离散扩展资源，默认按整数设备分配，不像 CPU 那样天然支持细粒度超卖。

2. 调度一致性

scheduler 根据 Pod 申请的扩展资源数量过滤节点，kubelet 也按同样数量调用 Device Plugin Allocate，二者需要一致。

3. Kubernetes 约定

扩展资源通常只允许设置 limits，requests 会被视为等于 limits，避免“调度申请少、运行占用多”的不一致。

4. 例外场景

MIG、MPS、time-slicing、vGPU 或 DRA 可以表达更复杂共享，但那是额外机制，不是普通 GPU limit 的默认语义。

面试口径：普通 GPU 扩展资源按整数设备调度和分配，所以 requests/limits 通常保持一致，保证 scheduler 与 kubelet 看到同一个资源需求。

Q: Node Affinity 和 nodeSelector 有什么区别？什么时候用哪个？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. nodeSelector

最简单的节点选择方式，只支持精确匹配（key=value），AND 逻辑。适合简单场景：GPU 节点打标签 gpu=true，Pod 配 nodeSelector: gpu: "true"。

2. Node Affinity

支持更丰富的表达式：In、NotIn、Exists、DoesNotExist、Gt、Lt。支持软约束（preferred）和硬约束（required）。适合复杂场景：优先选 SSD 节点，但 HDD 也可以接受。

3. 选择建议

简单标签匹配用 nodeSelector，需要表达式或软约束用 Node Affinity。两者可以同时使用，都满足才调度。

面试口径：nodeSelector 是简单版，Node Affinity 是增强版。需要软约束、复杂表达式或多条件组合时用 Affinity。

Q: Topology Spread Constraints 和 Pod Anti-Affinity 有什么区别？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 约束模型不同

Pod Anti-Affinity 是"每对 Pod 之间"的约束，Pod 数量越多，需要检查的配对越多，复杂度 O(n²)。Topology Spread 是"每个拓扑域 Pod 数量差距不超过 N"，复杂度与域数量相关。

2. 表达能力不同

Anti-Affinity 只能表达"不能在一起"，Spread 可以表达"尽量均匀分布"且允许一定的 skew。Spread 的 maxSkew 参数让约束更灵活。

3. 大规模场景

大规模 Deployment（数百 Pod）用 Anti-Affinity 会导致调度器性能问题，推荐用 Topology Spread Constraints。

面试口径：Anti-Affinity 是二元的"不能在一起"，Spread 是量化的"差距不超过 N"。大规模均匀分布优先用 Spread。

Q: Taint 和 Toleration 的工作原理是什么？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 工作机制

Taint 是打在节点上的"排斥标记"，包含 key、value 和 effect。Toleration 是 Pod 的"容忍声明"。scheduler 在 Filter 阶段检查 Pod 是否容忍节点的所有 Taint，不容忍则过滤掉该节点。

2. 三种 Effect

NoSchedule 阻止新 Pod 调度；PreferNoSchedule 尽量阻止但不强制；NoExecute 会驱逐已在运行的 Pod。

3. 典型场景

GPU 节点打 nvidia.com/gpu:NoSchedule，GPU Pod 配对应 Toleration。节点维护前打 maintenance:NoExecute 驱逐 Pod。

4. 与 Affinity 配合

Taint 是"推"（节点拒绝 Pod），Affinity 是"拉"（Pod 选择节点）。生产环境通常两者配合：Taint 做隔离，Affinity 做优选。

面试口径：Taint 是节点说"不"，Toleration 是 Pod 说"我可以"。两者配合实现节点隔离和专用节点池。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

内容模块

Scheduler 主链路

精通★☆☆⏱ 20 min

一句话结论

一次 Pod 调度要按端到端链路讲：API Server 保存未绑定 Pod，scheduler 通过队列和插件链选择 Node 并写回绑定结果，目标 Node 的 kubelet 再真正启动容器。队列机制解释 Pod 为什么会在 ActiveQ、BackoffQ、UnschedulableQ 之间流转。

复习定位

维度	内容
所属模块	Kubernetes 核心
章节类型	系统类
解决问题	围绕控制面、调度资源模型、Workload Controller、网络存储、安全多租户、排障和 AI Infra GPU/DRA 建立平台面试答案。
面试抓手	先讲 Watch Pod → Queue → Filter → Score → Bind → Kubelet Run，再补三队列和事件唤醒。

kube-scheduler 内部机制：为什么这部分放在 K8S

调度研究里有一类问题是通用算法问题，例如公平性、装箱、抢占和 backfill；另一类问题是 Kubernetes 运行时机制问题，例如调度队列、scheduler cache、assumed pod、plugin lifecycle、binding cycle。后者应该放在 K8S 模块，因为它回答的是：这些算法在 Kubernetes 里到底挂在哪个扩展点、读什么缓存、写什么状态、失败后如何恢复。

Scheduler 主链路高频面试问题索引

复习时不要按文件顺序硬背。面试官通常按问题追问，先定位问题类型，再展开对应链路。

面试官问法	先答什么	深挖入口
一个 Pod 如何被调度到 Node？	Watch Pod → Queue → Filter → Score → Bind → Kubelet Run	本节端到端路径
Pod 一定会进入 ActiveQ 吗？	不一定，SchedulingGates / PreEnqueue 可能在入队前挡住	本节 PreEnqueue 补充
Pod 为什么 Pending？	先看 FailedScheduling，再按 Filter 失败插件分类	资源模型 + Diagnosis / FitError
scheduler 为什么需要 cache？	避免每次调度访问 API Server，并支持 Assume 防止过度分配	Cache、扩展点与抢占
高优 Pod 调度不上怎么办？	没有 feasible node 时 PostFilter 触发抢占，但抢占不等于立刻运行	Preemption 深入
大集群 scheduler 怎么优化？	减少候选节点、控制重试、优化插件耗时、用 QueueingHint 精确唤醒	性能、打分与 HA + QueueingHint
自定义调度逻辑写哪里？	先判断是排序、过滤、打分、预留还是绑定前等待	Scheduler 插件与扩展

一次 Pod 调度的端到端路径

这部分不要只背“Filter、Score、Bind”三个词。面试官如果继续追问，会看你是否知道 Pod 创建、scheduler 决策、API Server 持久化、kubelet 执行 是四段不同职责。

从 Pod 创建到 kubelet 启动容器：scheduler 负责选 Node 并写回绑定结果，kubelet 负责在目标 Node 上真正创建 Pod。

用户/控制器创建 Pod
  ↓
API Server 写入 etcd（Pod.spec.nodeName 为空）
  ↓
Scheduler 监听到未调度 Pod
  ↓
调度队列 Scheduling Queue
  ↓
PreFilter
  ↓
Filter：筛选可用 Node
  ↓
PostFilter：必要时抢占
  ↓
Score：给 Node 打分
  ↓
NormalizeScore / Reserve
  ↓
Permit：可选等待/拒绝
  ↓
PreBind
  ↓
Bind：写入 Pod.spec.nodeName
  ↓
API Server 持久化绑定结果
  ↓
目标 Node 上的 kubelet 监听到该 Pod
  ↓
kubelet 拉镜像、创建容器、启动 Pod

1. Pod 创建与待调度状态

用户或控制器创建 Pod，例如 kubectl apply -f pod.yaml。如果 Pod 没有指定 spec.nodeName，它就是一个待调度 Pod。

spec:
  nodeName: ""

API Server 会把 Pod 对象写入 etcd。此时调度还没有发生，集群里只是多了一个“期望被运行、但还没选 Node”的对象。

2. Scheduler 发现 Pod 并进入队列

kube-scheduler 通过 informer / watch 机制监听 API Server，重点关注 Pod.spec.nodeName 为空的 Pod。它们会进入 scheduler 内部的调度队列。

队列	作用	一句话
`activeQ`	当前可以尝试调度的 Pod	现在试试
`backoffQ`	之前失败，等待退避时间结束的 Pod	过会儿再试
`unschedulableQ`	当前没有可行节点，等待集群状态变化的 Pod	等条件变了再试

调度器会不断从 activeQ 中取出一个 Pod，开始一次 Scheduling Cycle。

补充：Pod 不一定立刻进入 ActiveQ

新版 Kubernetes 里，Pod 进入正常调度队列前还可能被 SchedulingGates 或 PreEnqueue 拦住。这个点经常用来区分“只会背 Filter/Score”和“理解现代 scheduler”的候选人。

机制	发生位置	解决什么问题	面试口径
`spec.schedulingGates`	Pod 入队前	外部控制器还没准备好前，不让 Pod 进入调度队列	有 gate 的 Pod 不会进入正常调度循环，避免无效 Filter/Score
`PreEnqueue`	Queue 前的扩展点	插件可以在入队前判断 Pod 是否值得进入 ActiveQ	它比 PreFilter 更早，目标是减少无效入队
QueueingHint	调度失败后重新入队	判断某个集群事件是否真的可能让 Pod 变得可调度	它解决 UnschedulableQ 的惊群唤醒问题

收束句：不是所有 Pod 都马上进 ActiveQ；入队前有 gates，失败后有 QueueingHint，目的都是减少无效调度周期。

3. Scheduling Cycle：选择 Node

一次调度主要分成两个大阶段：Scheduling Cycle 负责选择 Node，Binding Cycle 负责把结果写回 API Server。Scheduling Cycle 的目标是为当前 Pod 找到一个最合适的 Node。

阶段	做什么	面试抓手
PreFilter	提前计算后续过滤会用的信息，例如资源请求、PVC、亲和性、拓扑约束、端口需求	能算一次的，不要在每个 Node 上重复算
Filter	遍历候选 Node，判断每个 Node 能不能运行这个 Pod	回答“能不能放”
PostFilter	Filter 没有可行节点时执行，典型动作是抢占	失败后的补救，不是常规打分
PreScore / Score	给可行节点打分，选出最优 Node	回答“放哪里最好”
NormalizeScore	把插件分数归一化到统一范围	不同插件分数才能加权汇总
Reserve	在调度器内部先预留资源	防止并发调度重复占用同一资源
Permit	可选地允许、拒绝或等待	Gang Scheduling 常用

4. Filter：筛选可用 Node

Filter 会得到一批可行节点，例如 feasibleNodes = [node-a, node-c, node-f]。如果为空，就说明当前 Pod 暂时无法调度。

过滤条件	例子	失败后常见现象
资源是否足够	Node 剩余 CPU / Memory / GPU 是否满足 Pod requests	`Insufficient cpu`、`Insufficient memory`、`Insufficient nvidia.com/gpu`
NodeSelector / NodeAffinity	Pod 要求 `disk=ssd` 或必须是 A100 节点	节点很多但标签不匹配
Taints / Tolerations	Node 有 `dedicated=gpu:NoSchedule`，Pod 没有 toleration	被 `TaintToleration` 插件过滤
PodAffinity / AntiAffinity	必须靠近某类 Pod，或不能和同服务副本同节点	拓扑域或已有 Pod 分布不满足
Volume 约束	PV 是否能挂载到该 Node，volume zone 是否匹配	PVC / VolumeBinding 相关 FailedScheduling
HostPort 冲突	Pod 使用 `hostPort: 8080`	目标 Node 已有 Pod 占用相同端口

5. PostFilter：调度失败后的抢占

如果 Filter 阶段没有任何 Node 可用，会进入 PostFilter。最典型的动作是 Preemption：当前高优先级 Pod 调度不上时，尝试驱逐某些低优先级 Pod 腾出资源。

找到一些候选 Node
  ↓
模拟删除低优先级 Pod
  ↓
判断当前 Pod 是否可以放上去
  ↓
选出最合适的抢占目标
  ↓
设置 nominatedNodeName

注意：抢占不是立刻完成绑定，而是先让低优先级 Pod 进入删除流程；目标资源真正释放后，Pod 才有机会重新调度成功。

6. Score：给可行节点打分

如果 Filter 后存在多个可行 Node，调度器会进入 Score 阶段。每个打分插件会给 Node 一个分数，通常归一化到 0 ~ 100，最终加权求和。

finalScore(node) =
  pluginA_score * weightA +
  pluginB_score * weightB +
  pluginC_score * weightC

打分维度	作用
资源分布策略	`LeastAllocated` 倾向空闲节点，`MostAllocated` 倾向装箱，`RequestedToCapacityRatio` 支持自定义利用率曲线
镜像本地性	Node 上已有镜像时得分更高，减少镜像拉取时间
亲和性偏好	`preferredDuringSchedulingIgnoredDuringExecution` 这类软约束影响打分，不决定能不能调度
拓扑分布	尽量让副本分散到不同 Node / Zone / Region，减少单点风险

如果多个 Node 同分，调度器会做一定的随机化或稳定选择，避免热点集中。

7. Reserve、Permit、PreBind 与 Bind

阶段	作用	失败处理
Reserve	选出目标 Node 后，在 scheduler 内部先为这个 Pod 预留资源	后续失败时执行 `Unreserve` 释放预留状态
Permit	可选阶段，可以允许绑定、拒绝绑定或等待一段时间	等待超时或拒绝时触发回滚
PreBind	绑定前处理，例如 volume binding、外部插件最终校验、自定义资源准备	失败则不会进入 Bind
Bind	向 API Server 发起绑定请求，把 Pod 更新为 `spec.nodeName = selected-node`	失败后进入调度失败处理
PostBind	绑定成功后的通知型动作，例如记录事件、异步上报	通常不影响 Pod 已经绑定的事实

关键点：Reserve / Assume 解决 scheduler 本地并发一致性，Bind 解决 API Server 中的持久化状态。

8. kubelet 发现并启动 Pod

API Server 接收到绑定请求后，会更新 Pod 对象并写入 etcd。此时 Pod 对象变成：

spec:
  nodeName: node-a

目标 Node 上的 kubelet 会监听 spec.nodeName == 当前节点名 的 Pod。发现新 Pod 后，它进入 SyncPod 流程：

获取 PodSpec
  ↓
创建 Pod sandbox
  ↓
调用 CNI 配置网络
  ↓
挂载 volume
  ↓
拉取镜像
  ↓
通过 CRI 调用 container runtime
  ↓
创建容器
  ↓
启动容器
  ↓
上报 Pod 状态

如果使用 containerd，路径大致是 kubelet → CRI → containerd → runc / kata / gVisor。

职责边界：Scheduler 不负责起容器

组件	职责
kube-scheduler	决定 Pod 放到哪个 Node
API Server	保存 Pod 对象和绑定结果
etcd	持久化集群状态
kubelet	在目标 Node 上真正创建和运行 Pod
container runtime	创建容器进程
CNI	配置 Pod 网络
CSI / volume plugin	挂载存储

一句话：Scheduler 只负责“选机器”，不负责“起容器”；容器真正启动是在 kubelet 侧完成的。

源码口径的简化路径

ScheduleOne
  ↓
NextPod
  ↓
SchedulingCycle
  ↓
PreFilter
  ↓
Filter
  ↓
PostFilter if needed
  ↓
Score
  ↓
SelectHost
  ↓
Reserve
  ↓
Permit
  ↓
BindingCycle
  ↓
PreBind
  ↓
Bind
  ↓
PostBind

最核心的是：Filter 判断能不能放，Score 判断放哪里最好，Bind 把结果写回 API Server。

记忆版：Watch Pod → Queue → Filter → Score → Bind → Kubelet Run。

调度队列总览图

这张图要抓住一个核心：队列系统决定“下一个被尝试调度的是谁”，Filter/Score 才决定“它放到哪里”。因此队列策略会直接影响等待时间、公平性、吞吐和重试风暴。

一个 Pod 在调度队列里的流转过程

下面用最直观的文本流程图展示 Pod 从创建到绑定（或失败重试）的完整路径：

新 Pod 创建
    ↓
进入 ActiveQ
    ↓
调度器从 ActiveQ 取出 Pod
    ↓
尝试调度（Filter → Score → Assume）
    ↓
    ├── 成功 ──→ 进入绑定流程（Bind → PostBind）
    │
    └── 失败 ──→ 
        ├── 放入 BackoffQ ：等一段时间再试，避免 CPU tight loop
        │    ↓ 退避时间到期后回到 ActiveQ
        │
        └── 放入 UnschedulableQ ：等集群状态变化再试
             ↓ Node/Pod/PVC/ResourceClaim 事件触发 Move request 后回到 ActiveQ

核心记忆：ActiveQ 是"现在试试"，BackoffQ 是"过会儿再试"，UnschedulableQ 是"等条件变了再试"。调度器的吞吐和延迟很大程度上取决于这三个队列之间的流转策略。

三个队列分别解决什么问题

调度器用三个队列管理不同状态的 Pod，而不是把所有 Pod 放在一个队列里轮询。理解这三个队列的进入条件、退出条件、排序策略和设计意图，是面试中区分“会用 K8s”和“理解调度器”的关键。

维度	ActiveQ	BackoffQ	UnschedulableQ
一句话	现在试试	过会儿再试	等条件变了再试
进入条件	新 Pod 创建、BackoffQ 到期、事件触发 Move request	调度失败且失败原因不是“永久不可调度”	调度失败且当前没有任何节点满足条件
退出条件	被调度器取出尝试调度	退避时间到期后移回 ActiveQ	集群事件（Node/Pod/PVC 变化）触发 Move request
排序策略	QueueSort 插件：默认按 priority 降序 + 入队时间	按退避到期时间排序（FIFO）	不排序，等待事件驱动唤醒
核心问题	谁先获得调度机会？队头阻塞、饥饿、公平性	失败后多久重试？退避过短浪费 CPU，过长增加延迟	什么时候唤醒？事件提示不精准会导致无效重试风暴
AI 场景	小推理任务、交互式 Notebook 能否插队	GPU 大作业资源不够时避免频繁扫描节点	等待 GPU 释放、RDMA 节点加入、PVC 绑定、gang 资源凑齐
面试表达	Filter/Score 再聪明也只能处理已出队的 Pod；队列排序决定谁先获得机会	调度器的“冷静期”，把失败重试从忙等变成有节奏的再尝试	“条件未满足”的等待区；只有相关事件才应触发唤醒

一句话记住：ActiveQ 管“谁先上”，BackoffQ 管“别太急”，UnschedulableQ 管“等时机”。三个队列的流转策略直接影响调度器的吞吐、延迟和公平性。

Move request：为什么事件提示很关键

Move request 可以理解为“某个集群事件可能让一批不可调度 Pod 重新有机会”。调度器会根据失败原因和事件类型，决定是否把 Pod 从 UnschedulableQ 或 BackoffQ 移回 ActiveQ。

事件	可能唤醒哪些 Pod	为什么	无效唤醒风险
Node 新增或 Node label 变化	nodeSelector、nodeAffinity、拓扑约束失败的 Pod	节点集合或标签变了，Filter 结果可能改变	如果所有 Pod 都唤醒，会造成全量重试
Pod 删除或完成	资源不足、端口冲突、反亲和失败的 Pod	CPU/GPU/内存/端口/拓扑位置被释放	只释放 CPU 却唤醒 GPU 不足的 Pod，收益很低
PVC 绑定完成	之前因 volume binding 失败的 Pod	存储条件满足后才可能通过 Filter	和存储无关的 Pod 不应被大量唤醒
ResourceSlice / ResourceClaim 变化	DRA 设备匹配失败的 Pod	设备库存、属性或 claim 状态变化	设备事件过粗会导致大量 GPU Pod 重试
PodGroup / quota 变化	Gang、队列配额、批任务准入失败的 Pod	组资源或配额条件变化	准入条件未变化时重试只会消耗调度周期

队列性能优化不是“多重试几次”，而是“在正确事件发生后，只唤醒可能变得可调度的 Pod”。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

一句话结论

scheduler cache、assume、binding cycle 和 preemption 是理解调度一致性和抢占的关键。

复习定位

维度	内容
所属模块	Kubernetes 核心
章节类型	系统类
解决问题	围绕控制面、调度资源模型、Workload Controller、网络存储、安全多租户、排障和 AI Infra GPU/DRA 建立平台面试答案。
面试抓手	不要只讲算法，必须讲缓存状态和绑定路径。

调度问题定位：区分 Pod 属性、调度阶段和调度机制

在分析 Kubernetes Scheduler 时，需要区分三类概念，这三类概念不能混在一起：

Pod 属性：Pod 自身携带的信息，例如优先级、资源请求、节点选择约束等。
调度阶段 / 扩展点：Scheduler Framework 中处理 Pod 的流程位置，例如 QueueSort、Filter、Score、Reserve、Permit。
调度机制 / 策略：由多个阶段共同完成的行为，例如抢占、退避重试、Gang 调度、回填调度等。

例如，priority 是 Pod 的属性，它会影响队列排序和抢占，但它本身不是调度阶段。Preemption 是调度失败后的抢占机制，通常发生在没有可行节点之后，和 PostFilter 等流程有关，但它也不是普通的节点打分阶段。QueueSort、Filter、Score、Reserve、Permit 才是 Scheduler Framework 中更明确的扩展点。

三类概念对照表

类型	示例	说明
Pod 属性	`priority`、`resource requests`、`nodeSelector`、`affinity`、`tolerations`、`preemptionPolicy`	描述 Pod 自身需求或调度约束，不是调度阶段
调度阶段 / 扩展点	QueueSort、PreFilter、Filter、PostFilter、Score、Reserve、Permit、Bind、Unreserve	Scheduler Framework 中的处理流程，可以开发插件扩展
调度机制 / 策略	Preemption、Backoff、UnschedulableQ 重新入队、Gang Scheduling、Backfill、Quota 管理	通常横跨多个阶段，不一定对应单一扩展点

常见问题应该从哪里定位

问题	本质	主要涉及的调度阶段	相关 Pod 属性 / 机制	说明
高优先级 Pod 长时间没被调度	Pod 没有及时获得调度机会，或资源被低优任务占住	QueueSort、PostFilter	Pod 属性：priority 机制：Preemption	priority 影响队列排序和抢占；如果 Pod 未出队，先看 QueueSort；如果出队后无节点可放，再看抢占
Pod 反复扫描大量节点但失败	失败 Pod 被无效重新入队	SchedulingQueue、PreFilter、Filter	机制：Backoff、UnschedulableQ、事件提示	应优化重新入队条件，避免无关事件唤醒无关 Pod
短作业被大作业队头阻塞	出队顺序不合理	QueueSort	机制：Backfill、多队列	小作业没机会出队时，Score 不会生效
GPU 拓扑放置不合理	节点或设备组合选择不好	Filter、Score、Reserve	Pod 属性：resource requests、nodeAffinity、GPU topology	Pod 已进入调度周期，问题是放到哪里和怎么预留设备
Gang 任务部分 Pod 占住资源但整体无法启动	缺少整组准入与失败回滚	Reserve、Permit、Unreserve	机制：Gang Scheduling、PodGroup	需要整组 Pod 要么一起放行，要么一起回滚
高优任务无节点可放，但低优任务占着资源	资源不足，需要让低优任务让路	PostFilter	Pod 属性：priority、preemptionPolicy 机制：Preemption	没有可行节点时，Score 没意义，需要抢占制造可行节点

面试表达技巧：先区分"这是 Pod 属性问题、调度阶段问题还是调度机制问题"，再定位到具体扩展点或策略。不要把 priority 说成"调度阶段"，也不要把 Preemption 说成"打分的一部分"。

Scheduler Cache 与 Assume 机制

scheduler 不会每调度一个 Pod 都从 API Server 重新拉全量 Node 和 Pod。它维护本地 cache，并在调度周期开始时生成 snapshot。选中节点后，scheduler 会先在本地 cache 中 assume 该 Pod 已经占用资源，然后异步绑定。

机制	解决什么问题	风险
NodeInfo	缓存节点资源、Pod、镜像、本地状态	cache 与 API Server 存在短暂不一致
Snapshot	给一个调度周期提供稳定视图	不是强一致，只是调度器本地视角
Assumed Pod	绑定完成前先占住资源，避免过度分配	Bind 失败后必须过期或回滚
Nominated Pod	抢占时记录候选节点	被抢占 Pod 退出前，高优先级 Pod 仍可能等待

调度失败状态：不是所有 Pending 都一样

面试官问 Pod 为什么 Pending 时，不要只答“资源不够”。scheduler 内部会区分失败类型，这决定了后续是等待事件、退避重试、记录错误，还是进入抢占。

状态	含义	后续处理	例子
`Unschedulable`	当前没有满足条件的节点，但未来集群状态变化可能解决	进入失败处理，等待 QueueingHint / Move request 唤醒	资源暂时不足、PodAntiAffinity 暂时不满足
`UnschedulableAndUnresolvable`	普通事件很难让它变可调度，通常是硬约束本身不可能满足	减少无效重试，等待更强的配置变化	nodeSelector 指向不存在的标签、硬约束写错
`Error`	插件或内部执行异常，不是业务资源约束	记录 error，按失败路径处理并暴露事件/日志	插件读取 cache 失败、外部 extender 返回错误
`FitError`	没有 feasible node 时聚合出的调度失败结果	转成 FailedScheduling 事件，里面包含各插件失败原因	`0/100 nodes are available`

排查口径：Pending 先看 FailedScheduling 事件，再看是哪个 Plugin 产生了哪类 Status；不要把配置错误、资源不足和插件异常混成一类。

Assume / Reserve / Bind：三个“占用”不是一回事

这张表是面试里解释调度一致性的关键。scheduler 的本地状态、插件状态和 API Server 持久化状态是三层不同状态。

阶段	写哪里	解决什么问题	失败如何恢复
Assume	scheduler cache	Bind 还没完成前，先让后续调度周期看到资源已被占用，避免过度分配	Bind 失败或超时后 Forget assumed Pod
Reserve	插件自己的内存账本或状态	预留插件特有资源，例如 GPU 拓扑、MIG slot、PodGroup 名额	后续失败时调用 `Unreserve`
Bind	API Server / etcd	把最终结果持久化为 `spec.nodeName` 或 Binding 对象	失败后走调度失败路径，已 Reserve 的状态要回滚
PostBind	通常是事件、日志或外部通知	绑定成功后的通知，不再改变放置决策	一般不影响 Pod 已经绑定的事实

一句话：Assume 是 scheduler 本地先占位，Reserve 是插件状态先占位，Bind 是把结果写进 API Server。

Plugin 扩展点与调度研究问题的映射

研究问题	适合扩展点	说明
短作业优先 / SLA 排序	QueueSort	改变 Pod 出队顺序，影响全局等待时间
Gang Scheduling	PreFilter + Permit + Reserve	先识别 PodGroup，再在 Permit 阶段等待同组 Pod 凑齐
拓扑感知放置	PreFilter + Filter + Score	基于 NUMA、NVLink、机架、RDMA 等约束过滤和打分
多资源公平	QueueSort + Score + PostFilter	排序决定谁先获得机会，抢占决定如何回收资源
代价基抢占	PostFilter	调度失败后选择 victim，考虑 checkpoint、运行时长和释放资源量
DRA 设备匹配	PreFilter + Filter + Reserve	基于 ResourceClaim 和 ResourceSlice 做设备级匹配与预留

Preemption 深入

抢占不是简单地“杀掉低优先级 Pod 后马上运行高优先级 Pod”。scheduler 会先寻找通过移除低优先级 Pod 后可满足高优先级 Pod 的节点，选择 victim 后设置 nominatedNodeName，等待被抢占 Pod 优雅退出。期间如果集群状态变化，调度结果仍可能改变。

PDB：PodDisruptionBudget 会影响 victim 选择，减少对高可用服务的破坏。
Graceful termination：被抢占 Pod 有终止宽限期，高优先级 Pod 不能立刻拿到资源。
不可抢占约束：nodeSelector 不匹配、PVC 约束不满足、硬亲和性不满足，抢占也解决不了。
训练任务代价：AI 训练抢占要考虑 checkpoint 新鲜度、已运行时间、重启成本和 gang 语义。

抢占四问：面试官最常追

问题	回答抓手
抢占是不是直接杀 Pod？	不是。scheduler 选择 victim 后，低优 Pod 进入优雅删除流程；高优 Pod 通常先记录 `nominatedNodeName`，等待资源真正释放。
为什么抢占后高优 Pod 还 Pending？	victim 有 termination grace period；PDB 可能限制驱逐；同时集群状态可能变化，原 nominated node 未必最终可用。
`preemptionPolicy: Never` 是什么？	这个 Pod 可以有高 priority 参与排序，但不会主动抢占别人，适合高优但不想破坏其他任务的工作负载。
什么问题抢占也解决不了？	硬约束不匹配，例如 nodeAffinity 写错、PVC zone 不匹配、GPU 型号不存在、Taint 不容忍、端口冲突不可通过删除低优 Pod 解决。

Gang Scheduling → 见"任务调度理论"页面

Gang Scheduling 的理论基础（partial allocation、PodGroup/minAvailable、Backfill、弹性训练）和 K8s 实现细节（Coscheduling Plugin / Volcano / Kueue、Framework 扩展点落点、边界情况）已统一归并到 "任务调度理论" → "批调度、Gang 与 Backfill" 标签页。

快速索引：Gang 概念与 partial allocation → 任务调度理论 / 批调度、Gang 与 Backfill；Framework 扩展点落点 → 同上；Coscheduling / Volcano / Kueue 对比 → 同上；边界情况与坑 → 同上。

Q: 为什么说调度算法不能脱离 scheduler cache 和 binding cycle 讨论？

因为算法给出的只是“应该放哪里”，而 Kubernetes 还要解决并发绑定、缓存一致性、资源临时预留、失败回滚和 API Server 写入延迟。一个理论上最优的策略，如果不能处理 assume、reserve、unreserve、permit timeout 和抢占等待，在真实 kube-scheduler 中就不可落地。

Q: Scheduler Extender、Scheduler Plugin、多个 scheduler 怎么选？

新能力优先用 Scheduling Framework Plugin，因为它能接入完整生命周期和 scheduler cache；Extender 更像外部 HTTP 过滤/打分，延迟和一致性控制较弱；多个 scheduler 适合业务强隔离，但要避免不同 scheduler 同时竞争同一批资源造成策略冲突。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

一句话结论

Scheduler 性能调优关注候选节点比例、打分插件、profile、并发和 HA。

复习定位

维度	内容
所属模块	Kubernetes 核心
章节类型	系统类
解决问题	围绕控制面、调度资源模型、Workload Controller、网络存储、安全多租户、排障和 AI Infra GPU/DRA 建立平台面试答案。
面试抓手	解释 percentageOfNodesToScore 的收益与风险。

Scheduler 性能与扩展性

大规模集群（数千节点、数万 Pod）中，scheduler 的性能直接决定 Pod 启动延迟。面试中要能说清楚关键性能参数和优化手段。

机制	作用	默认值	调优建议
percentageOfNodesToScore	控制 Score 阶段扫描的节点比例	集群规模自适应（0-50%）	集群越大比例越低，平衡精度和性能
nodeScorePluginWeight	各打分插件的权重	默认各插件权重 1	根据业务调整，如提高拓扑分散权重
parallelism	并行调度的 worker 数量	默认 16	CPU 核数多可适当调高
leaderElection	多实例 HA，同时只有一个 active	默认开启	生产环境必须开启
podInitialBackoffSeconds	调度失败后的初始退避时间	1s	指数退避，最大 10s
podMaxBackoffSeconds	调度失败后的最大退避时间	10s	防止无限等待

percentageOfNodesToScore 的工作原理

scheduler 在 Score 阶段找到所有可用节点后，按比例只对部分节点打分（选最高分的），而不是对所有节点打分。这在大集群中显著减少计算量。公式：numNodes = max(100, min(集群节点数 × 比例, 集群节点数))。找到的节点会按 zone 分散，避免全部集中在同一可用区。

Scheduler 吞吐量估算

一个 scheduler 实例通常可以处理 100-500 Pod/s 的调度吞吐。瓶颈通常在 API Server 的写吞吐（Bind 操作）和 scheduler cache 的更新频率。多 scheduler 实例（HA 模式）不会提升吞吐，因为同一时刻只有一个 active。

Node 打分算法详解

Filter 阶段只是"能用"，Score 阶段才是"优选"。面试中要能说出至少 3 个打分插件的算法逻辑。

插件	打分逻辑	公式/策略	适用场景
NodeResourcesFit	资源越充足分越高	LeastAllocated：`(capacity - request) / capacity` 越大越好；MostAllocated：相反	装箱（MostAllocated）或分散（LeastAllocated）
NodeResourcesBalancedAllocation	CPU 和内存使用比例越接近分越高	`1 - \|cpuFrac - memFrac\|`，避免资源碎片	防止 CPU 用满但内存空闲的碎片节点
ImageLocality	节点已有镜像越多分越高	镜像大小加权求和	减少镜像拉取时间，加速 Pod 启动
InterPodAffinity	满足 Pod 亲和性规则加分	匹配的 Pod 越多分越高	数据本地性、缓存亲和
NodeAffinity	满足 preferred 规则加分	每条规则加权累加	节点优选
TaintToleration	容忍 PreferNoSchedule 加分	容忍越多分越高	软性节点隔离

LeastAllocated vs MostAllocated

LeastAllocated 把 Pod 分散到不同节点，适合需要高可用、避免单点故障的场景。MostAllocated 把 Pod 集中到少数节点，适合需要装箱率高、节省成本的场景。可以通过 NodeResourcesFit 插件的 scoringStrategy 配置切换。

自定义打分权重

在 KubeSchedulerConfiguration 中可以为每个插件设置权重。例如提高 NodeResourcesFit 权重让资源均衡更重要，提高 ImageLocality 权重让启动速度优先。

Scheduler 配置与多 Profile

Kubernetes 1.19+ 支持通过 KubeSchedulerConfiguration 文件配置 scheduler 行为，包括启用/禁用插件、设置插件权重、定义多个调度 Profile。

KubeSchedulerConfiguration 核心字段

profiles：定义多个调度 Profile，每个 Profile 可以有独立的插件配置。
plugins：按扩展点（Filter、Score、Reserve 等）启用或禁用插件。
pluginConfig：为特定插件提供配置参数，如 NodeResourcesFit 的 scoringStrategy。
leaderElection：配置 HA 和租约参数。

多 Profile 场景

同一个 scheduler 可以为不同 namespace 或不同 PriorityClass 的 Pod 使用不同的调度策略。例如：默认 Pod 用 LeastAllocated 分散，批处理 Pod 用 MostAllocated 装箱，GPU Pod 用自定义拓扑感知 Profile。

默认启用的插件

Kubernetes 默认 scheduler 启用了约 20 个插件，覆盖所有扩展点。面试中不需要全背，但要能说出核心几个：NodeResourcesFit、NodeAffinity、TaintToleration、ImageLocality、DefaultPreemption、DefaultBinder。

Scheduler HA 与 Leader Election

生产环境中通常部署多个 scheduler 实例实现高可用，但同一时刻只有一个 active 实例在工作。

概念	说明	关键参数
Leader Election	通过 etcd 的 Lease 机制选举 leader	`leaderElection.leaseDuration`（默认 15s）
Lease 续约	Leader 定期续约，证明自己还活着	`leaderElection.renewDeadline`（默认 10s）
故障转移	Leader 失联后，其他实例竞争成为新 leader	`leaderElection.retryPeriod`（默认 2s）
非 Leader 行为	Standby 实例不执行调度，只等待成为 leader	不消耗调度计算资源

故障转移时间

最坏情况下故障转移时间 ≈ leaseDuration + renewDeadline + retryPeriod，默认约 27s。可以通过调小这些参数降低故障转移时间，但会增加 etcd 压力。

多 Scheduler 模式

除了 HA 部署，Kubernetes 还支持运行多个不同配置的 scheduler（通过 schedulerName 指定）。例如默认 scheduler 处理普通 Pod，GPU scheduler 处理 GPU Pod。注意：不同 scheduler 之间不共享 cache，可能产生资源竞争。

Q: percentageOfNodesToScore 是什么？怎么调？

percentageOfNodesToScore 控制 scheduler 在 Score 阶段扫描的节点比例。默认值随集群规模自适应：100 节点以下扫全部，5000 节点以上扫 5%。调大可以提高调度精度（找到更优节点），但增加计算开销；调小可以提升性能，但可能错过最优节点。建议集群小于 500 节点时保持默认，超大集群按需调整。

Q: 如何保证 scheduler 的高可用？

通过部署多个 scheduler 实例 + Leader Election 实现。同一时刻只有一个 active 实例执行调度，其他 standby 等待。Leader 通过 etcd Lease 续约，失联后自动触发重新选举。关键参数：leaseDuration（默认 15s）、renewDeadline（默认 10s）、retryPeriod（默认 2s）。故障转移时间最坏约 27s。注意：HA 只保证可用性，不提升吞吐。

Q: LeastAllocated 和 MostAllocated 分别适合什么场景？

LeastAllocated 把 Pod 分散到不同节点，资源使用率更均匀，适合在线服务（需要 buffer 应对流量波动）。MostAllocated 把 Pod 集中到少数节点，装箱率更高，适合批处理任务（可以腾出整机做下线维护）。可以通过 NodeResourcesFit 插件的 scoringStrategy.type 切换。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

一句话结论

读 kube-scheduler 源码不要从插件细节开始，而要先抓住启动链路、Informer/Cache、调度循环、过滤打分、绑定循环这五条主线。Lark 文档提供的是源码阅读视角，适合作为 Scheduler 主链路和插件扩展内容的补充。

复习定位

维度	内容
所属模块	Kubernetes 核心 / Scheduler 内部机制
章节类型	源码阅读路径
解决问题	把 kube-scheduler 从二进制启动、cache 同步、scheduleOne 到 bindingCycle 的源码链路串起来
面试抓手	一句话：先讲 `Run → SchedulingQueue → scheduleOne → schedulePod → findNodesThatFitPod / prioritizeNodes / selectHost → bindingCycle`。

来源与使用方式

本页整理自 Lark 文档《万字长文详解 Kubernetes 调度器：kube-scheduler 实现》，重点吸收其源码阅读顺序和函数链路。原文更偏长篇源码剖析；本站保留面试复习需要的主线，不复制长代码。

源码阅读主线

主线	关键问题	关键入口
应用启动	kube-scheduler 二进制怎么启动，配置怎么进入 scheduler	`cmd/kube-scheduler/scheduler.go`、`NewSchedulerCommand`、`runCommand`、`Setup`
Informer / Cache	scheduler 从哪里拿 Pod/Node/PV/PVC 状态	`InformerFactory`、`DynInformerFactory`、`WaitForCacheSync`、scheduler cache
调度循环	未绑定 Pod 怎么被不断消费	`Scheduler.Run`、`SchedulingQueue.Run`、`scheduleOne`
选节点	怎么从所有 Node 找 feasible nodes 并打分	`schedulePod`、`findNodesThatFitPod`、`prioritizeNodes`、`selectHost`
绑定循环	选中节点后怎么写回 API Server	`bindingCycle`、`WaitOnPermit`、`PreBind`、`Bind`、`PostBind`

启动链路

main

cmd/kube-scheduler/scheduler.go 创建 cobra command

NewSchedulerCommand

构造 Options、flags、配置文件入口

runCommand

校验配置并调用 Setup

Setup

创建 CompletedConfig、Framework profile、scheduler 实例

Run

启动 informer/cache、Leader Election、最终调用 sched.Run(ctx)

面试里不需要背所有 flags，但要知道：scheduler 是通过 KubeSchedulerConfiguration、profiles、pluginConfig、extenders、parallelism、percentageOfNodesToScore 等配置组装出 Framework 和调度器实例的。

核心运行循环

Lark 文档里强调的主入口是：

func (sched *Scheduler) Run(ctx context.Context) {
    sched.SchedulingQueue.Run(logger)
    go wait.UntilWithContext(ctx, sched.scheduleOne, 0)
    <-ctx.Done()
    sched.SchedulingQueue.Close()
}

这段代码说明三件事：

scheduler 不是被动 RPC 服务，而是一个持续消费调度队列的控制循环。
SchedulingQueue 负责存储和唤醒待调度 Pod。
scheduleOne 是单个 Pod 调度的主流程。

scheduleOne 的函数链路

scheduleOne

从 SchedulingQueue 取一个 Pod

schedulingCycle

串行运行，为 Pod 选择一个节点

schedulePod

找可行节点、打分、选最高分节点

assume

在 scheduler cache 里先假定 Pod 占用资源

bindingCycle

并发执行 WaitOnPermit / PreBind / Bind / PostBind

failureHandler

失败时回队列、记录 FailedScheduling、触发抢占或退避

关键点：Scheduling Cycle 串行，Binding Cycle 可以和下一个 Pod 的 Scheduling Cycle 并发。这也是为什么 Reserve/Unreserve 和 Assume 很重要：绑定还没写 API Server 前，scheduler 本地 cache 必须先看到资源已被占用，避免后续 Pod 过度分配。

schedulePod 的三段式

Lark 文档中源码链路可以压缩成：

函数	对应扩展点	作用
`findNodesThatFitPod`	`PreFilter`、`Filter`、Extender Filter	找出 feasible nodes，并产出 `Diagnosis` / `NodeToStatus`
`prioritizeNodes`	`PreScore`、`Score`、`NormalizeScore`、Extender Prioritize	对 feasible nodes 打分并加权汇总
`selectHost`	非插件，最终选择	在最高分节点中选择一个，得分相同会做随机化，避免固定偏置

Diagnosis / FitError 为什么重要

调度失败时，findNodesThatFitPod 会把每个节点为什么不可行写到 Diagnosis.NodeToStatusMap 中。FitError 最终会变成 FailedScheduling 事件的一部分。

Filter 失败

每个 Node 记录失败 plugin 和原因

Diagnosis

聚合 NodeToStatusMap、UnschedulablePlugins、PreFilterMsg

FitError

没有 feasible node 时返回

Event

用户通过 kubectl describe pod 看到 FailedScheduling

QueueingHint

后续事件是否应该唤醒这个 Pod，依赖失败 plugin 的判断

这解释了为什么排查 Pending 不能只说“资源不足”：真实事件通常是多个 plugin 的聚合结果，例如 NodeResourcesFit、NodeAffinity、TaintToleration、VolumeBinding、PodTopologySpread。

与本站现有章节的关系

你想解决的问题	应该看
Pod 为什么 Pending	`调度与资源模型` + 本页的 `Diagnosis / FitError`
调度队列怎么流转	`Scheduler 主链路 / 调度路径与三个队列`
PreFilter/Filter/Score 为什么这么拆	`Scheduler 插件与扩展 / 扩展点设计差异`
写自定义 GPU 拓扑插件	`Scheduler 插件与扩展 / 自定义 Plugin 实战`
如何观测哪个 plugin 卡住	`Scheduler 插件与扩展 / Scheduler 可观测性`

关联模块

调度与资源模型：理解 Pod 需求和 Node 资源/约束。
Scheduler 主链路：理解队列、cache、assume、抢占和 HA。
Scheduler 插件与扩展：理解 Framework 扩展点和插件开发。
任务调度理论：理解 Gang、Backfill、抢占代价这些策略为什么需要挂到 scheduler 上。

内容模块

插件开发与扩展点

精通★☆☆⏱ 26 min

一句话结论

自定义调度逻辑优先用 Scheduling Framework Plugin，复杂系统再考虑 extender 或独立 scheduler。

复习定位

维度	内容
所属模块	Kubernetes 核心
章节类型	系统类
解决问题	围绕控制面、调度资源模型、Workload Controller、网络存储、安全多租户、排障和 AI Infra GPU/DRA 建立平台面试答案。
面试抓手	用 GPU 拓扑感知 Filter/Score 举例。

自定义 Scheduler Plugin 实战

面试中经常被问到"你有没有写过自定义调度插件"。回答时应该先讲清楚有哪些实现方式，再深入 Framework Plugin 的开发流程，最后给出具体代码示例。

三种实现自定义调度逻辑的方式

方式	原理	优点	缺点	适用场景
Scheduling Framework Plugin (In-tree)	实现 Framework 扩展点接口，编译进 scheduler 二进制	性能最好，直接访问 scheduler cache 和 NodeInfo；可以接入完整生命周期（QueueSort 到 PostBind）	需要重新编译 scheduler；升级 K8s 版本时需要适配接口变化	性能敏感的调度逻辑（GPU 拓扑、NUMA、Gang）；需要访问 cache 或参与 Reserve/Permit 等状态阶段
Scheduler Extender (Out-of-tree HTTP)	独立 HTTP 服务，scheduler 通过 HTTP 调用 Filter / Prioritize / Bind 等接口	独立部署，不侵入 scheduler 代码；可以用任意语言开发	HTTP 调用延迟高（ms 级）；无法访问 scheduler cache；只能参与 Filter / Score / Bind 等有限阶段	简单过滤逻辑（如特殊 label 过滤）；非性能敏感的定制需求；多语言团队
Multiple Scheduler (独立 Scheduler)	部署另一个完整的 scheduler 实例，Pod 通过 `schedulerName` 指定	完全独立，策略隔离；可以用不同版本的 scheduler	不同 scheduler 之间不共享 cache，可能产生资源竞争；运维复杂（需要维护两套 scheduler）	业务强隔离（GPU 任务 vs CPU 任务）；需要完全不同的调度策略

面试要点：三种方式的本质区别是"调度逻辑跑在 scheduler 进程内还是进程外"。Framework Plugin 跑在进程内，性能最好、能力最强，是 K8s 官方推荐方式。Extender 和 Multiple Scheduler 是历史兼容方案，新功能应优先考虑 Framework Plugin。

Scheduling Framework Plugin 开发详解

Scheduler Framework 定义了从 Pod 入队到绑定的完整生命周期，每个阶段都是一个扩展点（Extension Point）。开发自定义插件就是实现一个或多个扩展点接口。

Framework 扩展点全景

扩展点	类型	触发时机	典型用途
QueueSort	排序	Pod 进入 ActiveQ 时	自定义出队顺序（如短作业优先、SLA 排序）
PreFilter	过滤	Filter 之前，预处理 Pod 信息	计算 Pod 的调度约束、检查 PodGroup 完整性
Filter	过滤	对每个候选节点判断是否可用	GPU 拓扑匹配、NUMA 亲和、自定义资源检查
PostFilter	过滤	Filter 后无可用节点时	Preemption 抢占逻辑（选择 victim）
PreScore	打分	Score 之前，预处理打分数据	预计算节点统计信息
Score	打分	对每个候选节点打分	基于实时负载打分、拓扑分散打分
NormalizeScore	打分	Score 之后，归一化分数	将分数映射到统一范围
Reserve	预留	选中节点后，Bind 之前	预留 GPU 设备、标记资源已占用
Permit	许可	Reserve 之后，等待条件满足	Gang Scheduling 等待同组 Pod 凑齐
PreBind	绑定	Bind 之前，执行绑定前操作	挂载 Volume、分配 IP
Bind	绑定	将 Pod 绑定到节点	自定义绑定逻辑（极少需要）
PostBind	绑定	Bind 之后，通知型操作	记录调度事件、通知外部系统
Unreserve	回滚	Reserve 之后失败时	释放预留的 GPU 设备、清理临时状态

开发步骤（面试标准回答）

创建 Go 项目：初始化 Go module，引入 k8s.io/kubernetes 依赖（或使用 scheduler-plugins 仓库作为模板）。
实现扩展点接口：根据需求选择实现 FilterPlugin、ScorePlugin、ReservePlugin 等接口。每个接口有固定的方法签名。
实现 Name() 方法：返回插件名称，用于在配置文件中引用。
注册插件：在 main() 中通过 app.NewSchedulerCommand() 注册自定义插件到 Framework。
编译部署：编译为自定义 scheduler 二进制或镜像，替换默认 scheduler。
配置启用：在 KubeSchedulerConfiguration 的 profiles[].plugins 中启用插件，必要时在 pluginConfig 中传入参数。

关键接口签名（面试要能写出）

以下是最常用的三个接口签名，面试中如果被问到"写过什么插件"，至少能写出 Filter 和 Score 的签名：

接口	方法签名	返回值含义
FilterPlugin	`Filter(ctx, state, pod, nodeInfo) *Status`	`Success` 表示节点可用；`Unschedulable` 表示不可用
ScorePlugin	`Score(ctx, state, pod, nodeName) (int64, *Status)`	返回 0-100 的分数，分数越高越优先
ReservePlugin	`Reserve(ctx, state, pod, nodeName) *Status`	`Success` 表示预留成功；失败会触发 Unreserve

注意：CycleState 是单次调度周期内的临时状态存储，可以在 PreFilter 中写入数据，在 Filter/Score/Reserve 中读取，避免重复计算。

典型示例：GPU 拓扑感知 Filter + Score 插件

这是 AI Infra 面试中最常见的自定义插件场景。下面给出完整的实现思路和关键代码骨架。

场景描述

集群中有多种 GPU 拓扑的节点（如 NVLink 互联的 8 卡节点、PCIe 互联的 4 卡节点）。训练任务需要 4 张 NVLink 互联的 GPU，不能分配到 PCIe 节点上，也不能分配到 NVLink 域不够 4 卡的节点上。

实现思路

PreFilter：从 Pod annotation 中解析 GPU 拓扑需求（如 gpu-topology: nvlink-4），写入 CycleState。
Filter：从 Node label 中读取 GPU 拓扑信息（如 nvidia.com/gpu-topology: nvlink-8），判断是否满足 Pod 需求。不满足则返回 Unschedulable。
Score：对满足条件的节点，根据 NVLink 域剩余 GPU 数量打分：刚好满足需求（如剩余 4 卡域）给高分，碎片化严重的给低分。
Reserve：在 scheduler cache 中标记具体哪些 GPU 被预留，防止后续 Pod 重复分配。

Filter 核心代码骨架

func (p *GPUTopologyPlugin) Filter(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
    nodeInfo *framework.NodeInfo,
) *framework.Status {
    // 1. 从 CycleState 读取 PreFilter 阶段解析的 GPU 需求
    data, err := state.Read(stateKeyGPURequirement)
    if err != nil {
        return framework.NewStatus(framework.Error, err.Error())
    }
    requirement := data.(*GPURequirement) // topology=nvlink, count=4

    // 2. 从 Node label 读取 GPU 拓扑信息
    node := nodeInfo.Node()
    topoLabel, ok := node.Labels["nvidia.com/gpu-topology"]
    if !ok {
        return framework.NewStatus(framework.Unschedulable, "node has no GPU topology label")
    }

    // 3. 判断拓扑是否匹配
    if topoLabel != requirement.Topology {
        return framework.NewStatus(framework.Unschedulable,
            fmt.Sprintf("GPU topology mismatch: need %s, got %s",
                requirement.Topology, topoLabel))
    }

    // 4. 检查可用 GPU 数量（从 nodeInfo 或 annotation 获取）
    availableGPUs := getAvailableGPUs(node, nodeInfo)
    if availableGPUs < requirement.Count {
        return framework.NewStatus(framework.Unschedulable,
            fmt.Sprintf("insufficient GPUs: need %d, available %d",
                requirement.Count, availableGPUs))
    }

    return framework.NewStatus(framework.Success)
}

Score 核心代码骨架

func (p *GPUTopologyPlugin) Score(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
    nodeName string,
) (int64, *framework.Status) {
    // 从 CycleState 读取 GPU 需求
    data, _ := state.Read(stateKeyGPURequirement)
    requirement := data.(*GPURequirement)

    // 获取该节点上剩余 GPU 的拓扑分布
    node := getNodeByName(nodeName)
    freeGPUDomains := getFreeNVLinkDomains(node)

    // 打分策略：刚好满足需求的域越多，分数越高
    // 避免把 Pod 放到"只剩最后一个 4 卡域"的节点上
    matchingDomains := 0
    for _, domain := range freeGPUDomains {
        if domain.FreeGPUs >= requirement.Count {
            matchingDomains++
        }
    }

    // 分数范围 0-100
    score := int64(matchingDomains * 25)
    if score > 100 {
        score = 100
    }
    return score, framework.NewStatus(framework.Success)
}

KubeSchedulerConfiguration 配置示例

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: gpu-scheduler
    plugins:
      preFilter:
        enabled:
          - name: GPUTopology
      filter:
        enabled:
          - name: GPUTopology
      score:
        enabled:
          - name: GPUTopology
            weight: 10   # 权重越高，拓扑因素越重要
      reserve:
        enabled:
          - name: GPUTopology
    pluginConfig:
      - name: GPUTopology
        args:
          topologyTypes:
            - nvlink
            - pcie
          defaultCount: 1

面试表达结构：先说明"有三种实现方式，我选择 Framework Plugin 因为性能最好、能力最全" → 再讲"我实现了 PreFilter + Filter + Score + Reserve 四个扩展点" → 最后给出 Filter/Score 的核心逻辑和配置。如果能写出接口签名和关键代码骨架，会大幅加分。

案例：AIJob 驱动的预测调度插件

面试官常追问："如果让你做一个预测调度器，既预测任务运行时间，又预测多个任务共置时的干扰程度，你怎么落到 Kubernetes Scheduler Framework 里？" 推荐统一回答成 AIJob CRD + AIJob Operator + Scheduler Plugin 三层架构：AIJob 表达深度学习任务，AIJob Operator 管生命周期和预测子控制器，scheduler plugin 只读辅助 CRD。

层次	组件	职责	边界
任务表达层	`AIJob` CRD	表达模型、batch size、replica、GPU 需求、checkpoint、共置容忍度	不直接做节点选择
节点采集层	DCGM Exporter / Node GPU Collector	采集 SM、HBM、PCIe/NVLink、显存、进程级 GPU memory、训练 step time	只采集和暴露指标，不做调度决策
任务控制面	AIJob Operator	创建 PodGroup / Pods，维护任务状态，并通过预测子控制器写 `PredictionResult` 与 `NodeGpuProfile`	不在 scheduler 进程内运行模型
调度热路径	Predictive Scheduler Plugin	通过 Informer 本地缓存 CRD，在 QueueSort / Filter / Score / Reserve 中查表决策	Filter / Score 绝不发 RPC，不拉 Prometheus

核心边界：AIJob Operator 负责"任务生命周期 + 预测状态生产"；scheduler plugin 负责"读取预测状态并做放置决策"。

① 控制面数据流：统一走 CRD

这条链路避免了大对象写入 Pod annotation，也让预测结果有独立生命周期、状态、GC 和权限控制。

步骤	动作	产物
1. 提交任务	用户提交 `AIJob`，声明模型、GPU、replica、checkpoint、共置容忍度	AIJob 对象
2. 采集	节点侧 DCGM Exporter 暴露 GPU counter，训练框架暴露 throughput / step time	Prometheus / TSDB 中的历史样本
3. 建模	AIJob Operator 的预测子控制器周期训练 runtime 模型和共置 retention 矩阵	模型文件、特征版本、job-signature 聚类
4. 写 CRD	AIJob Operator 为 AIJob 写 `PredictionResult`，为节点写 `NodeGpuProfile`	结构化预测状态
5. 本地缓存	Scheduler Plugin 在初始化时建立 Informer	`jobUID → PredictionResult`、`nodeName → NodeGpuProfile`
6. 调度决策	QueueSort / PreFilter / Filter / Score / Reserve 只查本地 map	微秒级读路径

② CRD 设计：AIJob、PredictionResult 与 NodeGpuProfile

apiVersion: scheduling.predictor.io/v1
kind: AIJob
metadata:
  name: resnet50-train
  namespace: train
spec:
  framework: pytorch
  replicas:
    workers: 8
  resources:
    gpu:
      count: 8
      type: A100
  workload:
    model: resnet50
    batchSize: 256
    precision: fp16
  scheduling:
    queue: research
    minAvailable: 8
    allowColocation: true
    minRetention: 0.90
  checkpoint:
    enabled: true
    intervalSeconds: 600
status:
  phase: Pending
  predictionRef:
    name: pred-resnet50-train

apiVersion: scheduling.predictor.io/v1
kind: PredictionResult
metadata:
  name: pred-resnet50-train
  namespace: train
spec:
  jobRef:
    kind: AIJob
    name: resnet50-train
    uid: "aijob-uid-1234"
status:
  jobSignature: "resnet50-bs256-fp16"
  predictedRuntimeSeconds: 3600
  confidence: 0.86
  minRetention: 0.90
  interferenceProfile:
    bert-large:
      retention: 0.92
      slowdown: 1.08
    gpt2-medium:
      retention: 0.78
      slowdown: 1.28

apiVersion: scheduling.predictor.io/v1
kind: NodeGpuProfile
metadata:
  name: gpu-node-42
status:
  nodeName: gpu-node-42
  gpuUtilization: 0.62
  hbmBandwidthUtilization: 0.48
  colocatedJobSignatures:
    - bert-large
    - gpt2-medium
  avgRetentionIfAdd: 0.84
  updatedAt: "2026-06-15T15:00:00Z"

对象	谁写	谁读	生命周期
`AIJob`	用户 / 平台	AIJob Operator、Scheduler Plugin	训练任务生命周期
`PredictionResult`	AIJob Operator 的预测子控制器	Scheduler Plugin	跟随 AIJob 创建和删除，可 ownerReference 绑定 AIJob
`NodeGpuProfile`	AIJob Operator / Node collector controller	Scheduler Plugin	跟随 Node，周期更新状态

③ PredictionResult 的生命周期与消费路径

PredictionResult 不是用户手写的主资源，而是 AIJob Operator 为调度器准备的辅助状态。它的核心作用是把“深度学习任务画像”转换成 scheduler plugin 能低延迟读取的结构化字段。

阶段	什么时候发生	谁做	结果怎么被感知
创建	AIJob 创建后，Operator 第一次 Reconcile，解析 spec 中的模型、batch size、GPU、replica、checkpoint、共置容忍度	AIJob Operator 的预测子控制器	创建 `PredictionResult`，并把 `AIJob.status.predictionRef` 指过去
初始预测	AIJob 还没运行时，基于历史任务、模型画像和资源请求估计 runtime / retention	预测子控制器	更新 `PredictionResult.status`，scheduler plugin 的 Informer 收到 update
调度消费	Pod 进入调度队列并执行 QueueSort / PreFilter / Filter / Score	Scheduler Plugin	从本地 cache 按 `jobUID` 读取，不访问 API Server，不调模型
运行中校准	Pod 绑定后，训练框架上报 step time，DCGM 上报 GPU counters	AIJob Operator / metric collector	异步修正 `PredictionResult.status.confidence`、runtime 或 retention
完成回收	AIJob Succeeded / Failed / Deleted	AIJob Operator	把真实 runtime / throughput 写入训练样本；通过 ownerReference GC PredictionResult

用户怎么使用它

用户通常不直接创建 PredictionResult，只提交 AIJob。如果要排查，可以通过 kubectl get/describe predictionresult 看预测运行时间、置信度、共置风险和更新时间。它更像 PVC 的绑定状态：用户关心结果，但不手写细节。

调度器怎么使用它

Scheduler Plugin 在初始化时建立 Informer，把 PredictionResult 放进本地索引，例如 jobUID → PredictionResult。调度时从 Pod ownerReference / label 找到所属 AIJob，再查本地 cache。这样 QueueSort / Filter / Score 都是内存读取，不会阻塞调度周期。

func (r *AIJobReconciler) reconcilePrediction(ctx context.Context, job *aiv1.AIJob) error {
    // 1. 从 AIJob spec 提取任务画像：模型、batch size、GPU、replica、checkpoint。
    features := buildFeatures(job.Spec)

    // 2. 调用预测模块；这是控制面异步逻辑，不在 scheduler 热路径。
    pred := r.predictor.Predict(ctx, features)

    // 3. Upsert PredictionResult，并通过 ownerReference 绑定 AIJob 生命周期。
    result := buildPredictionResult(job, pred)
    if err := controllerutil.SetControllerReference(job, result, r.Scheme); err != nil {
        return err
    }
    return r.Client.Status().Update(ctx, result)
}

一句话：PredictionResult 在 AIJob 创建后的 Reconcile 中产生，运行中异步校准；用户用它排查预测状态，scheduler plugin 用它做本地查表决策。

④ 各扩展点职责与 Go 骨架

下面代码只展示关键路径。真实实现中还需要错误处理、metrics、并发保护、feature gate 和配置化权重。

QueueSort：预测运行时间只做第三排序键

func (pl *PredictivePlugin) Less(p1, p2 *framework.QueuedPodInfo) bool {
    // 1. PriorityClass 仍然是第一优先级，避免预测策略破坏 K8s 语义。
    if *p1.Pod.Spec.Priority != *p2.Pod.Spec.Priority {
        return *p1.Pod.Spec.Priority > *p2.Pod.Spec.Priority
    }

    // 2. 租户公平性第二优先级，QAD 越低表示越需要补偿资源。
    qad1 := pl.fairness.QAD(p1.Pod.Namespace)
    qad2 := pl.fairness.QAD(p2.Pod.Namespace)
    if qad1 != qad2 {
        return qad1 < qad2
    }

    // 3. 运行时间预测来自 AIJob 对应的 PredictionResult，本地 cache 读取。
    rt1 := pl.predStore.RuntimeSeconds(jobUID(p1.Pod))
    rt2 := pl.predStore.RuntimeSeconds(jobUID(p2.Pod))
    if rt1 != rt2 {
        return rt1 < rt2
    }

    // 4. 最后用入队时间打破平局，避免不稳定排序。
    return p1.Timestamp.Before(p2.Timestamp)
}

PreFilter：把 CRD 预测值写入 CycleState

func (pl *PredictivePlugin) PreFilter(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
) (*framework.PreFilterResult, *framework.Status) {
    pred := pl.predStore.GetByJobUID(jobUID(pod))
    if pred == nil {
        // 冷启动兜底：AIJob 还没有 PredictionResult 时走保守策略。
        pred = conservativePrediction(pod)
    }

    // CycleState 只在本次 scheduling cycle 内有效，避免后续阶段重复查 CRD cache。
    state.Write(stateKeyPrediction, &PodPredictionState{
        RuntimeSeconds:      pred.RuntimeSeconds,
        JobSignature:        pred.JobSignature,
        MinRetention:        pred.MinRetention,
        InterferenceProfile: pred.InterferenceProfile,
    })
    return nil, framework.NewStatus(framework.Success)
}

Filter：共置干扰超过阈值就拒绝节点

func (pl *PredictivePlugin) Filter(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
    nodeInfo *framework.NodeInfo,
) *framework.Status {
    pred := readPredictionState(state)
    nodeName := nodeInfo.Node().Name
    nodeProfile := pl.nodeProfileStore.Get(nodeName)

    // 节点画像缺失时走保守策略：Guaranteed 任务拒绝共置，BestEffort 可降级打分。
    if nodeProfile == nil && isGuaranteed(pod) {
        return framework.NewStatus(framework.Unschedulable, "missing NodeGpuProfile")
    }

    retention := minPredictedRetention(pred, nodeProfile.ColocatedJobSignatures)
    if retention < pred.MinRetention {
        return framework.NewStatus(
            framework.Unschedulable,
            fmt.Sprintf("predicted retention %.2f below threshold %.2f", retention, pred.MinRetention),
        )
    }
    return framework.NewStatus(framework.Success)
}

Score：在可行节点里选择更低干扰、更好装箱的节点

func (pl *PredictivePlugin) Score(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
    nodeName string,
) (int64, *framework.Status) {
    pred := readPredictionState(state)
    nodeProfile := pl.nodeProfileStore.Get(nodeName)

    // interferenceScore 越高表示共置越安全。
    retention := minPredictedRetention(pred, nodeProfile.ColocatedJobSignatures)
    interferenceScore := int64(retention * 100)

    // MostAllocated 风格：优先填补已有 GPU 利用率较高但仍安全的节点。
    binPackScore := int64(nodeProfile.GPUUtilization * 100)
    topologyScore := pl.topology.Score(pod, nodeName)

    score := interferenceScore*5 + binPackScore*2 + topologyScore*3
    return normalize(score), framework.NewStatus(framework.Success)
}

Reserve / Unreserve：维护插件自己的共置账本

func (pl *PredictivePlugin) Reserve(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
    nodeName string,
) *framework.Status {
    pred := readPredictionState(state)
    // scheduler cache 只知道整数资源；共置 signature 账本由插件自己维护。
    pl.ledger.Add(nodeName, pod.UID, pred.JobSignature)
    return framework.NewStatus(framework.Success)
}

func (pl *PredictivePlugin) Unreserve(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
    nodeName string,
) {
    // Bind / Permit / PreBind 失败时必须回滚，避免后续 Pod 看到假的共置状态。
    pl.ledger.Remove(nodeName, pod.UID)
}

⑤ 干扰信号怎么形成闭环

阶段	输入	输出	为什么不放在 scheduler 内
单跑画像	任务单独运行时的 throughput、step time、GPU counters	job-signature 的 baseline	需要历史窗口和聚合计算
共置画像	两个 job-signature 共置时的 throughput 变化	retention / slowdown 矩阵	需要离线统计和异常值清洗
在线更新	Pod 绑定后的真实 runtime、实际 retention、驱逐事件	更新 PredictionResult / 训练样本	异步闭环，不能阻塞调度
调度使用	本地 Informer cache 中的 CRD 状态	QueueSort / Filter / Score 决策	热路径只查内存，保证 P99

面试要点：干扰不是 scheduler 实时测的，而是 Operator 用历史和在线反馈维护 CRD；scheduler 看到的是已经算好的结构化状态。

⑥ 30 秒 / 2 分钟 / 追问应答

30 秒

我会把预测调度器拆成 AIJob Operator 和 Scheduler Plugin 两部分。用户提交 AIJob，Operator 负责展开 PodGroup / Pods、管理 checkpoint 和任务状态，同时预测子控制器从 Prometheus / DCGM / 训练框架指标中训练 runtime 和 interference 模型，并把结果写入 PredictionResult 和 NodeGpuProfile。Scheduler Plugin 只用 Informer 把这些 CRD 缓存在本地：QueueSort 用预测运行时间做第三排序键，Filter 用共置 retention 做硬阈值，Score 在可行节点里选择干扰更小、装箱更好的节点，Reserve / Unreserve 维护插件自己的共置账本。

2 分钟

整体链路是：用户提交 AIJob；AIJob Operator 把它转换成 PodGroup / Pods，并维护任务状态；节点侧 DCGM Exporter 和训练框架暴露 GPU counters、step time、throughput；Operator 的预测子控制器周期拉取历史样本，训练运行时间模型和 job-signature 之间的 retention 矩阵；对每个 AIJob 生成 PredictionResult，对每个 GPU 节点维护 NodeGpuProfile。scheduler plugin 初始化时建立 Informer，把这些 CRD 放进本地 cache。

调度时，QueueSort 先看 PriorityClass，再看租户公平性，最后才看 predicted runtime，避免短任务优先饿死长任务。PreFilter 从本地 cache 读取当前 Pod 所属 AIJob 的 PredictionResult 写入 CycleState。Filter 读取 NodeGpuProfile 和节点上已共置任务的 signature，预测 retention 低于阈值就返回 Unschedulable。Score 对可行节点综合 interference、bin packing 和 topology 打分。Reserve 把本次 Pod 的 signature 写入插件账本，Bind 失败通过 Unreserve 回滚。

这套设计的核心是热路径隔离：模型训练、推理、样本回收全部在 Operator 异步做；scheduler 只做内存查表和轻量计算，因此不会把 Filter / Score 放大成 RPC 风暴。

面试官可能追问

追问	回答抓手
为什么用 AIJob，而不是只有 PredictionResult？	AIJob 表达训练任务语义：模型、batch size、replica、GPU、checkpoint、minAvailable、共置容忍度。PredictionResult 只是 AIJob 的调度辅助状态。
为什么不用 Pod annotation？	预测结果是结构化状态，可能包含 runtime、confidence、干扰矩阵、版本和更新时间；CRD 可独立 watch、GC、鉴权和演进，不污染 Pod 对象。
为什么不在 Filter 里直接 gRPC 调模型？	Filter 是节点级并行热路径，节点数越多 RPC 越多；scheduler P99 必须稳定，所以只读 Informer 本地 cache。
预测不准怎么办？	用 confidence 和安全 margin；低置信度走保守策略；PostBind 后回收真实 runtime 和 retention；SLO 破坏时驱逐低优共置伙伴。
冷启动没有 PredictionResult 怎么办？	Guaranteed 任务保守拒绝高风险共置；BestEffort 可用 namespace / AIJob 类型历史中位数和默认 retention；同时 AIJob Operator 尽快补齐 CRD。
怎么证明有效？	看调度延迟、JCT、waiting time、GPU 利用率、SLO violation、实际 retention；做 ablation：去掉 runtime 排序、去掉 interference Filter、去掉 interference Score。

收束：预测运行时间决定“先调谁”，共置干扰预测决定“能不能放和放哪里”；预测值统一由 Operator 写 CRD，scheduler plugin 只通过 Informer 本地缓存读取。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

一句话结论

PreFilter / Filter / PreScore / Score 看似只是流程拆分，背后是「全局串行预处理 vs 节点级并行处理」的架构选择，决定了一个插件应该把代码写到哪个 Hook 里。

复习定位

维度	内容
所属模块	Kubernetes 核心 / Scheduler 内部机制
章节类型	设计类
解决问题	自定义插件时不会再写错扩展点；面试能答清"为什么要拆成两段"
面试抓手	一句话：Pre 阶段做集群级预处理（串行、能终止周期、写 CycleState），Filter/Score 阶段做节点级判断（并行、只能影响当前节点）。

调度框架全景图

下面这张是 kubernetes/enhancements/keps/sig-scheduling/624-scheduling-framework 设计文档里给出的官方流程图。先记图，再背扩展点。

PreEnqueue → Scheduling Cycle（PreFilter / Filter / PreScore / Score / NormalizeScore / Reserve / Permit）→ Binding Cycle（WaitOnPermit / PreBind / Bind / PostBind）。Scheduling Cycle 串行，Binding Cycle 可与下一个 Pod 的 Scheduling Cycle 并发。

PreFilter vs Filter：为什么必须拆开

核心差异表

维度	PreFilter	Filter
阶段目标	数据预处理 + 全局状态检查	节点级过滤，逐节点检查条件
数据流	写入共享数据到 `CycleState`	从 `CycleState` 读取数据并过滤节点
执行顺序	所有 PreFilter 插件顺序执行（串行）	Filter 插件并行执行，多协程跨节点（默认 16 协程）
终止能力	可以提前终止整个调度周期（如 Pod 不合法、PodGroup 不齐）	仅排除当前节点，不影响其它节点判断
调用次数	每个调度周期调用一次	每个候选节点调用一次（节点数 × 插件数）
典型工作	解析 Pod annotation、查 PodGroup 状态、构建拓扑索引、计算资源需求	检查节点资源、Taint、Affinity、Volume、自定义约束

设计哲学：能在 PreFilter 算一次的事，绝不在 Filter 里对每个节点重复算。这是 Filter 阶段并行化的前提。

为什么要这样切：一个具体例子

假设你写一个「Pod 必须放在和它的 PodGroup 其他成员同 zone 的节点上」插件：

查 PodGroup 当前已绑定到哪些 zone：这是一次集群级查询，所有节点都用同一个结果。如果放在 Filter 里，N 个节点会查 N 次，性能爆炸。
正确做法：PreFilter 里查一次写入 CycleState["targetZones"] = [...]；Filter 里只做 node.zone in targetZones 这种 O(1) 判断。

这同时解释了为什么 Filter 能并行：每个 goroutine 只读 CycleState（已经写完的不可变数据）+ 当前 NodeInfo，没有写竞争。

PreScore vs Score：同样的设计套路

核心差异表

维度	PreScore	Score
阶段目标	全局数据准备，避免重复计算	节点级打分，按策略生成优先级
数据粒度	集群级 / 候选节点列表级	单节点级
执行频率	每个调度周期一次	每个候选节点一次
输出影响	不直接参与最终决策，只准备中间数据	直接影响节点排名（0–100）

典型例子：PodTopologySpread 在 PreScore 里统计每个拓扑域当前已有多少 Pod；Score 里只做「这个节点所在域是不是欠的最多」的查表打分。

NormalizeScore：被忽略的第三段

Score 出来的原始分可能不在 [0, MaxNodeScore] 区间内。NormalizeScore 是同一个插件的最后机会对自己所有节点的分数做一次归一化（线性缩放、对数压缩等），保证不同插件的分数能加权合并。

阶段	单位	跨节点视野
PreScore	一次	全局
Score	节点	单节点
NormalizeScore	一次	本插件的所有节点分数列表

Plugin 与 Hook 的多对多结构

K8s scheduler 框架的优雅之处：一个插件可以挂多个 Hook，一个 Hook 可以挂多个插件，一个 Hook 内可以注册多种策略。下面三段代码是 kube-scheduler 源码里的真实写法。

1. 一个插件挂多个 Hook（NodeAffinity）

// pkg/scheduler/framework/plugins/nodeaffinity/node_affinity.go
var _ framework.PreFilterPlugin    = &NodeAffinity{}
var _ framework.FilterPlugin       = &NodeAffinity{}
var _ framework.PreScorePlugin     = &NodeAffinity{}
var _ framework.ScorePlugin        = &NodeAffinity{}
var _ framework.EnqueueExtensions  = &NodeAffinity{}

这五行 `var _ = ...` 是什么写法

这是 Go 里一个常见的编译期接口实现校验技巧：

var _ framework.FilterPlugin = &NodeAffinity{} 这一行不引入任何运行时变量（_ 是空标识符），但会强制编译器检查 *NodeAffinity 是否实现了 framework.FilterPlugin 接口的所有方法。
少写一个方法 → 编译失败，不会等到运行时才报错。
面试可以答："这是一种零运行时开销的接口契约校验，K8s、etcd、Docker 等大型 Go 项目都在用。"

2. 一个 Hook 挂多个插件（ScorePlugin）

// 这些都在不同的 plugin 目录里，全部实现了 ScorePlugin
var _ framework.ScorePlugin = &NodeAffinity{}        // nodeaffinity
var _ framework.ScorePlugin = &Fit{}                 // noderesources（默认 LeastAllocated）
var _ framework.ScorePlugin = &BalancedAllocation{}  // noderesources（CPU/Mem 均衡）
var _ framework.ScorePlugin = &TaintToleration{}     // tainttoleration
var _ framework.ScorePlugin = &PodTopologySpread{}   // podtopologyspread

调度器最终给某个节点的总分 = Σ (插件分 × 插件权重)。权重在 KubeSchedulerConfiguration 里配置，不重新编译就能改。

3. 一个插件在一个 Hook 里挂多种策略（NodeResourcesFit）

// pkg/scheduler/framework/plugins/noderesources/resource_allocation.go
var nodeResourceStrategyTypeMap = map[config.ScoringStrategyType]scorer{
    config.LeastAllocated: func(args *config.NodeResourcesFitArgs) *resourceAllocationScorer {
        return &resourceAllocationScorer{
            Name:      string(config.LeastAllocated),
            scorer:    leastResourceScorer(args.ScoringStrategy.Resources),
            resources: args.ScoringStrategy.Resources,
        }
    },
    config.MostAllocated: func(args *config.NodeResourcesFitArgs) *resourceAllocationScorer {
        return &resourceAllocationScorer{
            Name:      string(config.MostAllocated),
            scorer:    mostResourceScorer(args.ScoringStrategy.Resources),
            resources: args.ScoringStrategy.Resources,
        }
    },
    config.RequestedToCapacityRatio: func(args *config.NodeResourcesFitArgs) *resourceAllocationScorer {
        return &resourceAllocationScorer{
            Name:      string(config.RequestedToCapacityRatio),
            scorer:    requestedToCapacityRatioScorer(args.ScoringStrategy.Resources, args.ScoringStrategy.RequestedToCapacityRatio.Shape),
            resources: args.ScoringStrategy.Resources,
        }
    },
}

三种策略对应三种调优目标：LeastAllocated 撒胡椒面、MostAllocated bin packing、RequestedToCapacityRatio 自定义曲线。具体公式见「设计理念与经典插件案例」一节的 NodeResources 部分。

kube-scheduler 源码目录地图

读源码时不要从 main.go 入手。先读 framework/interface.go 弄清接口定义，再看 runtime/framework.go 怎么把插件串起来，最后再追 schedule_one.go 主循环。

kubernetes/pkg/scheduler/
├── apis/                       # KubeSchedulerConfiguration 结构、参数校验
├── framework/                  # 调度框架核心
│   ├── interface.go            # 所有扩展点接口定义（必读起点）
│   ├── cycle_state.go          # CycleState 线程安全状态读写
│   ├── types.go                # NodeInfo、PodInfo、QueuedPodInfo
│   ├── events.go               # 调度事件记录
│   ├── extender.go             # 外部 Extender 的 HTTP 通信
│   ├── listers.go              # 本地 Node/Pod cache 查询
│   ├── parallelize/            # 并行 Filter 工具（默认 16 协程）
│   ├── preemption/             # 抢占公共逻辑（PostFilter 复用）
│   ├── plugins/                # 内置插件（nodeaffinity、noderesources、…）
│   ├── runtime/                # 插件注册、配置加载、依赖解析
│   └── autoscaler_contract/    # 与 Cluster Autoscaler 交互的协议
├── backend/                    # SchedulingQueue、Scheduler Cache 实现
├── profile/                    # 多 Profile 支持（一台 scheduler 跑多套配置）
├── schedule_one.go             # 单 Pod 调度主循环（schedulingCycle / bindingCycle）
└── scheduler.go                # Scheduler 结构体、Run() 入口

核心数据载体：

// pkg/scheduler/scheduler.go
type Scheduler struct {
    Cache             internalcache.Cache         // 实时 Node / Pod 状态，pod 中心设计
    SchedulingQueue   internalqueue.SchedulingQueue // 待调度 Pod 队列
    // ...
}

// pkg/scheduler/schedule_one.go 主流程
// Scheduler.schedulingCycle()
//   ├── Scheduler.schedulePod()
//   │   ├── findNodesThatFitPod()
//   │   │   ├── Framework.RunPreFilterPlugins()
//   │   │   └── findNodesThatPassFilters()
//   │   │       └── Framework.RunFilterPluginsWithNominatedPods()
//   │   └── prioritizeNodes()
//   │       ├── Framework.RunPreScorePlugins()
//   │       └── Framework.RunScorePlugins()
//   ├── Framework.RunReservePluginsReserve()
//   └── Framework.RunPermitPlugins()
// Scheduler.bindingCycle()
//   ├── Framework.WaitOnPermit()
//   ├── Framework.RunPreBind()
//   └── Scheduler.bind() → Framework.RunBindPlugins() → Framework.RunPostBindPlugins()

关联模块

上一节：Scheduler 内部机制 · 调度路径与队列，理解 ActiveQ → Cycle → Bind 的整体流转。
下一节：QueueingHint 与 Move Request，理解 Pod 失败后怎么回到 ActiveQ。
自定义 Plugin 实战：把这里讲的 Hook 设计落到代码里。

一句话结论

QueueingHint 是 K8s 1.28 引入、1.32 GA 的能力，让 Plugin 可以基于具体的集群事件（增删 Pod / Node 标签变更等）告诉 scheduler「这次事件能不能让我之前调度失败的 Pod 重新有机会」，避免惊群式重新入队导致 scheduler 反复扫描节点却仍然失败。

复习定位

维度	内容
所属模块	Kubernetes 核心 / Scheduler 内部机制
章节类型	系统类 + 设计类
解决问题	大规模集群下 UnschedulableQ → ActiveQ 的精确唤醒；理解 Move Request 的触发链路；面试能讲清"集群事件 → 唤醒哪些 Pod"
面试抓手	集群事件不是无差别广播给所有 Pending Pod，而是通过 QueueingHint 精确投递。

三个队列再回顾

ActiveQ（堆，按优先级排序）/ BackoffQ（堆，按 backoff 到期时间排序）/ UnschedulableQ（map，按调度失败原因记录）。

三队列职责

队列	数据结构	语义	出队条件
ActiveQ	堆（priority + timestamp）	等待立即调度的 Pod	scheduler 主循环 `Pop()`
BackoffQ	堆（backoff 到期时间）	调度刚失败、还在退避中的 Pod	backoff 时间到 → 自动迁移到 ActiveQ
UnschedulableQ	map[uid]Pod	调度失败、需要事件唤醒的 Pod	QueueingHint 命中、定时刷盘（默认 5 分钟）

三个队列的关键是 UnschedulableQ：不被自动唤醒，必须靠"集群事件 + QueueingHint"主动捞回去。

QueueingHint：从惊群到精确唤醒

没有 QueueingHint 时的"惊群"问题

K8s 1.28 之前的逻辑很粗糙：只要集群中发生了某种类型的事件（比如新 Node 加入、Pod 删除），scheduler 会把 UnschedulableQ 中**所有相关 Plugin 的 Pod** 一股脑搬回 ActiveQ。

误唤醒：新加入一台 GPU=A100 的节点，原本因为「内存不足」失败的 Pod 也会被唤醒。
反复扫描：这些 Pod 出队后会重新跑 PreFilter/Filter，绝大多数仍然失败、再回到 UnschedulableQ，浪费 CPU 和锁。
调度延迟放大：5000 节点 + 10000 Pending Pod 的集群，惊群一次可能让 scheduler 卡 1-2 秒。

QueueingHint 的设计

QueueingHint 让每个 Plugin 通过实现 EnqueueExtensions 接口告诉 scheduler：

我关心哪些事件类型：例如 NodeAffinity 关心 Node 增删和 Node Label 更新；NodeResourcesFit 关心 Node 增删和 Node 资源量更新；TaintToleration 关心 Node Taint 变化。
事件发生时，能不能让这个 Pod 重新有机会：返回 QueueingHint 的三种值：

返回值	含义	scheduler 行为
`Queue`	这个事件可能让 Pod 重新可调度	把 Pod 从 UnschedulableQ 移到 BackoffQ（或 ActiveQ）
`QueueSkip`	这个事件和 Pod 失败原因无关	Pod 留在 UnschedulableQ
`QueueAfterBackoff`	移动，但要走 backoff（已废弃，1.32 后等价于 Queue）	同 Queue

事件 → Plugin.QueueingHintFn(pod, event) → 返回 Queue / QueueSkip → scheduler 决定是否搬移 Pod。

EnqueueExtensions 接口示例

// NodeAffinity 插件实现 EnqueueExtensions
func (pl *NodeAffinity) EventsToRegister(_ context.Context) ([]framework.ClusterEventWithHint, error) {
    return []framework.ClusterEventWithHint{
        {
            Event: framework.ClusterEvent{
                Resource: framework.Node,
                ActionType: framework.Add | framework.UpdateNodeLabel,
            },
            QueueingHintFn: pl.isSchedulableAfterNodeChange,
        },
    }, nil
}

// QueueingHint 函数：判断这次 Node 变化是否可能让 Pod 变可调度
func (pl *NodeAffinity) isSchedulableAfterNodeChange(
    logger klog.Logger,
    pod *v1.Pod,
    oldObj, newObj interface{},
) (framework.QueueingHint, error) {
    _, newNode, err := schedutil.As[*v1.Node](oldObj, newObj)
    if err != nil {
        return framework.Queue, err
    }
    // 只有当新节点的 label 满足 Pod 的 NodeAffinity 时才唤醒
    affinity, _ := nodeaffinity.NewLazyErrorNodeSelector(pod.Spec.Affinity.NodeAffinity)
    if affinity.Match(newNode) {
        return framework.Queue, nil
    }
    return framework.QueueSkip, nil
}

面试要点：QueueingHint 把"是否唤醒"的判断**下沉到具体 Plugin**，因为只有 Plugin 自己知道"我之前为什么失败、这次事件能不能让我成功"。

Move Request：UnschedulableQ → ActiveQ 的触发链路

Move Request 来源

Move Request（也叫 cluster event）是 scheduler 内部抽象，统一表达"集群中发生了某种可能影响 Pending Pod 的变化"。下面是触发 Move Request 的全部来源：

事件来源	触发场景	Resource	ActionType
Node 增删	新节点加入 / 节点下线	Node	Add / Delete
Node 状态变化	Allocatable 变化、Taint 增删、Label 变更、Condition 变化	Node	UpdateNodeAllocatable / UpdateNodeTaint / UpdateNodeLabel / UpdateNodeCondition
Pod 删除	已运行 Pod 被删除（释放资源）	Pod	Delete
Pod 更新	Pod label 变化（影响 Pod Affinity）	Pod	UpdatePodLabel
PVC / StorageClass 增删	VolumeBinding 插件关心	PersistentVolumeClaim / StorageClass	Add / Update
CSINode / CSIDriver 变化	VolumeZone、NodeVolumeLimits 关心	CSINode / CSIDriver	Add / Update
Scheduler 自身周期事件	UnschedulableQ flush（默认 5 分钟）	—	定时器触发，无差别移动所有 Pod

Move Request 的处理流程

事件接收：EventHandler 监听 informer，收到对象变化。
构造 ClusterEvent：把 informer event 翻译成 {Resource, ActionType} 二元组。
遍历 UnschedulableQ：对每个 Pending Pod，找到所有曾经失败的 Plugin。
调用 QueueingHintFn：对每个 Plugin 调用其注册的 hint 函数，传入 oldObj / newObj。
决策：只要有一个 Plugin 返回 Queue，就把 Pod 搬到 BackoffQ；全部返回 QueueSkip 则留在 UnschedulableQ。

关键 trick：Plugin 返回 QueueSkip 不代表 Pod 永远不再被尝试 —— 5 分钟的 flush 定时器仍然会兜底，避免 hint 函数有 bug 时 Pod 永远卡死。

Q: 1.28 之前 K8s 用什么机制把 Pod 从 UnschedulableQ 唤醒？为什么要换成 QueueingHint？

1.28 之前：每个 Plugin 通过 EventsToRegister() 注册关心的 ClusterEvent 类型，scheduler 一旦收到匹配类型的事件，就把 UnschedulableQ 里所有"失败 Plugin 包含这个 Plugin"的 Pod 一次性全搬走。

问题：事件粒度太粗。例如 NodeAffinity 注册了 Node.UpdateLabel，但任何一次 Node 标签变化都会唤醒所有因 NodeAffinity 失败的 Pod，而绝大多数 Pod 关心的标签和这次变化的标签根本不是同一个。

1.28 引入 QueueingHint：在原来的"事件类型匹配"基础上，加一层 Plugin 级别的精确判断函数，只有 Plugin 自己确认"这次事件可能让我成功"才搬移。

1.32 GA：默认开启，所有内置 Plugin 都已实现 hint 函数。

Q: 一个 Pod 因为 NodeResourcesFit + NodeAffinity 同时失败进了 UnschedulableQ。新加入了一个 Node，但 label 不满足这个 Pod 的 NodeAffinity。这个 Pod 会被唤醒吗？

会被唤醒。新 Node 加入触发 Node.Add 事件，scheduler 会对这个 Pod 涉及的所有失败 Plugin 调用 hint：

NodeResourcesFit.hint: 新节点资源充足 → 返回 Queue。
NodeAffinity.hint: 新节点 label 不匹配 → 返回 QueueSkip。

只要有一个 Plugin 返回 Queue，就搬移。原因是 scheduler 没法证明"NodeResourcesFit 满足但 NodeAffinity 不满足 = 一定调度不了"，必须重新跑一遍 Filter 才知道。这是设计上的"宁可错放，不可漏放"。

关联模块

调度路径与三个队列（09a）：三队列基础和入队出队主流程。
Cache、扩展点与抢占（09b）：CycleState 与 scheduler cache 的关系。
Scheduler 可观测性（09g）：QueueingHint 命中率的 metrics 监控。

一句话结论

排查 scheduler 问题的标准三件套：kube-scheduler-simulator 重放 + Diagnosis / FitError 数据结构看每个节点被哪个 Plugin 拦下来 + Prometheus metrics 看长期趋势和 SLO。

复习定位

维度	内容
所属模块	Kubernetes 核心 / Scheduler 内部机制
章节类型	系统类 + 排障类
解决问题	知道"Pod Pending"问题怎么逐层下钻；面试能给出具体的 metric 名和 SLO 阈值
面试抓手	看一个 Pod 为什么 Pending → describe pod 看 events → FitError 里的 NodeToStatus → 长期趋势看 metrics。

工具一：kube-scheduler-simulator

是什么、为什么需要

kube-scheduler-simulator（sig-scheduling 官方维护，github.com/kubernetes-sigs/kube-scheduler-simulator）是一个本地 scheduler + Web UI，能在不动生产集群的前提下：

导入快照：把生产集群的 Node / Pod / PVC / PriorityClass 等对象一键导入。
重放调度：用同一份 KubeSchedulerConfiguration 跑一遍调度，看每个 Pod 在哪些 Plugin 失败、得分如何。
Mock Plugin：支持注入 mock 插件，可以预设某个 Plugin 在某个节点上的返回值，用来构造极端场景。
新插件验证：开发自定义 Plugin 时，先在 simulator 上跑通，再部署到 staging。

simulator 的 Web UI 可以可视化查看每个 Pod 在每个节点上各 Plugin 的得分和 Filter 通过情况。

典型使用流程

# 1. 启动 simulator（容器化或 docker compose）
docker compose up -d

# 2. 从生产集群导出快照
kubectl get nodes,pods,pvc,sc,priorityclass -A -o yaml > snapshot.yaml

# 3. 通过 simulator UI 或 API 导入
curl -X POST http://localhost:1212/api/v1/import \
     -H "Content-Type: application/yaml" \
     --data-binary @snapshot.yaml

# 4. 创建一个测试 Pod，观察调度结果
# UI 会展示：哪些节点被 Filter 过滤，每个节点 Score 是多少

面试可以加分的点：你做过什么调度问题排查 → "我用 kube-scheduler-simulator 把生产快照拉下来，本地复现了 Pending"。

工具二：Diagnosis / FitError 数据结构

findNodesThatFitPod 返回的诊断数据

当一个 Pod 调度失败，findNodesThatFitPod() 会返回 framework.Diagnosis，描述"为什么没找到合适节点"。这是 kubectl describe pod 里 FailedScheduling 事件背后的数据源。

scheduler 源码 pkg/scheduler/schedule_one.go 中 findNodesThatFitPod 返回 Diagnosis 的关键路径。

Diagnosis / FitError 字段拆解

字段	类型	含义
`NodeToStatus`	`map[string]*Status`	每个节点最终的失败状态（Unschedulable / UnschedulableAndUnresolvable / Error）和拦下它的 Plugin 名
`UnschedulablePlugins`	`sets.Set[string]`	本次调度中哪些 Plugin 至少在某个节点上返回了 Unschedulable —— 用于 QueueingHint 决定哪些 Plugin 关心后续事件
`PendingPlugins`	`sets.Set[string]`	返回 Pending 状态的 Plugin（暂时无法判断、等待外部信号）
`PreFilterMsg`	`string`	PreFilter 阶段直接拒绝时的消息（terminates the entire cycle）
`PostFilterMsg`	`string`	PostFilter（抢占）阶段的诊断消息

看一个真实的 FailedScheduling 事件

$ kubectl describe pod my-gpu-pod
Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  10s   default-scheduler  0/100 nodes are available:
    3 node(s) had untolerated taint {node.kubernetes.io/not-ready: },
    5 node(s) didn't match Pod's node affinity/selector,
    90 Insufficient nvidia.com/gpu,
    2 node(s) didn't match pod anti-affinity rules.
  preemption: 0/100 nodes are available:
    3 Preemption is not helpful for scheduling,
    97 No preemption victims found for incoming pod.

这条消息直接来自 NodeToStatus 的聚合 + PostFilterMsg。每一行就是一个 Plugin 在多少个节点上返回 Unschedulable。

面试拆解技巧：看到 FailedScheduling 先**按 Plugin 分类**：资源类（NodeResourcesFit）/ 节点选择类（NodeAffinity / NodeSelector）/ 隔离类（TaintToleration）/ 拓扑类（PodAffinity / PodTopologySpread）/ 设备类（VolumeBinding）。每类对应一组排查动作。

工具三：Prometheus Metrics 与 SLO

scheduler 核心 metrics 全景

Metric	类型	含义	SLO 参考阈值
`scheduler_pending_pods`	Gauge（按 queue 分类）	当前在 ActiveQ / BackoffQ / UnschedulableQ 的 Pod 数	UnschedulableQ < 100；持续增长说明有"集体 Pending"
`scheduler_scheduling_duration_seconds`	Histogram（按结果分类）	单个 Pod 调度周期耗时（含 Filter+Score+Bind）	P99 < 100ms；P99 > 1s 通常是 plugin 性能问题
`scheduler_schedule_attempts_total`	Counter（result=scheduled/unschedulable/error）	调度尝试次数	unschedulable / total < 1%
`scheduler_preemption_attempts_total`	Counter	抢占尝试次数	持续增长说明高优 Pod 资源不足
`scheduler_pod_scheduling_attempts`	Histogram	一个 Pod 从入队到最终调度成功经历了多少次尝试	P99 < 5；说明 backoff/重试不健康
`scheduler_plugin_execution_duration_seconds`	Histogram（按 plugin / extension_point 分类）	每个 Plugin 在每个扩展点的耗时	单个 Plugin P99 < 10ms
`scheduler_queue_incoming_pods_total`	Counter（按 event 分类）	各种事件触发了多少次 Pod 入队	用来定位"哪个事件源在制造惊群"
`scheduler_unschedulable_pods`	Gauge（按 plugin 分类）	当前因哪个 Plugin 失败而 Pending 的 Pod 数	定位"是不是某个 Plugin 配置错"
`scheduler_pod_scheduling_duration_seconds`	Histogram	Pod 创建 → 成功调度的端到端时间（含队列等待）	P99 < 30s（一般业务）；GPU 大任务可能需要数分钟

核心 PromQL 查询示例

# 1. 调度成功率（5 分钟窗口）
sum(rate(scheduler_schedule_attempts_total{result="scheduled"}[5m]))
/ sum(rate(scheduler_schedule_attempts_total[5m]))

# 2. P99 调度延迟
histogram_quantile(0.99,
  sum(rate(scheduler_scheduling_duration_seconds_bucket[5m])) by (le))

# 3. 找出"卡得最久"的 Plugin
topk(5,
  histogram_quantile(0.99,
    sum(rate(scheduler_plugin_execution_duration_seconds_bucket[5m])) by (le, plugin)))

# 4. UnschedulableQ 增长趋势
sum(scheduler_pending_pods{queue="unschedulable"})

# 5. 哪个 Plugin 拦下了最多 Pod
topk(5, sum(scheduler_unschedulable_pods) by (plugin))

三件套联动：一次 Pod Pending 排查路径

排查 SOP

第一步：单 Pod 现场。 kubectl describe pod <name> 看 FailedScheduling 事件，按 Plugin 分类拆解。
第二步：确认共性。 看 scheduler_unschedulable_pods{plugin=...}，判断是单个 Pod 配置问题还是多个 Pod 同时被某 Plugin 拦下。
第三步：本地复现。 如果是共性问题，用 simulator 拉快照本地重放，验证假设。
第四步：长期趋势。 看 scheduler_scheduling_duration_seconds P99 + scheduler_plugin_execution_duration_seconds，确认是不是新部署的 Plugin 引入的性能回退。
第五步：修正反馈。 修配置 / 加节点 / 调 Plugin 顺序，再用 simulator 验证一次。

面试加分项：能给出具体的 metric 名和阈值，比"我会看监控"具体得多。

Q: scheduler_pending_pods 持续增长，应该怎么排查？

1. 先按 queue label 拆：

queue="active" 增长 → scheduler 处理速度跟不上入队速度，看调度延迟和 plugin 性能。
queue="backoff" 增长 → 大量 Pod 调度失败正在 backoff，看 schedule_attempts_total{result="unschedulable"}。
queue="unschedulable" 增长 → 集群资源真的不够，或 QueueingHint 没正确唤醒，看 unschedulable_pods 按 plugin 分布。

2. 配合 plugin 维度： topk(5, sum(scheduler_unschedulable_pods) by (plugin)) 直接定位"哪个 Plugin 在拦人"。

3. 看入队源： scheduler_queue_incoming_pods_total 看是不是某个事件源（NodeAdded / PodDeleted）在制造惊群。

Q: P99 调度延迟从 50ms 突然涨到 800ms，怎么定位？

第一招：按扩展点拆。 scheduler_plugin_execution_duration_seconds 带 extension_point label，分别看 Filter / Score / PreFilter 的 P99，看延迟卡在哪个阶段。

第二招：按 plugin 拆。 同一个 metric 带 plugin label，topk 找出最慢的 Plugin。常见嫌疑：自定义插件没有缓存、PodAffinity 在大集群上 O(n²) 扫描、外部 Extender HTTP 调用超时。

第三招：和事件相关性。 看延迟跳升时间点和发布、节点变更、流量峰值是否对应。

关联模块

调度路径与三个队列（09a）：三队列流转。
Cache、扩展点与抢占（09b）：FailedScheduling 事件中 PreFilter / PostFilter 消息的来源。
QueueingHint 与 Move Request（09f）：unschedulable_pods 与 hint 命中率的关系。
性能、打分与 HA（09c）：percentageOfNodesToScore 和调度延迟的关系。

一句话结论

kube-scheduler 的设计理念是可扩展性 + 效率优先 + 声明式 API + 公平性 + HA + 用户可配置性六维平衡；NodeAffinity / TaintToleration / NodeResourcesFit 这些经典插件都是这套设计哲学的具体落地；Extender 是上一代的扩展方式，主要用 HTTP 通信。

复习定位

维度	内容
所属模块	Kubernetes 核心 / Scheduler 内部机制
章节类型	设计类 + 系统类
解决问题	面试被问"K8s scheduler 设计的核心理念是什么"能答出六维矩阵；理解经典插件如何把设计哲学落地；知道 Extender 和 Plugin 的边界
面试抓手	任何一个 Plugin 都可以放到「六维矩阵」里去解释它存在的理由。

K8s 整体架构定位

scheduler 是控制面组件之一。它通过 API Server 获取未调度 Pod 和 Node 状态，决策结果通过 Bind API 写回 API Server。

设计理念六维矩阵

六维设计目标

维度	含义	对应机制	典型权衡
可扩展性	支持业务定制调度逻辑，而不是改 scheduler 源码	Scheduling Framework Plugin、Extender、Multiple Scheduler、DRA	性能（in-tree）vs 灵活性（out-of-tree HTTP）
效率优先	大集群下保证调度延迟可控	percentageOfNodesToScore、Filter 并行、Snapshot、Cache	调度质量 vs 调度速度
声明式 API	用户描述"想要什么"，不是"怎么做"	Pod.spec.affinity / tolerations / topologySpreadConstraints	表达力 vs 复杂度
公平性	避免大作业饿死小作业、避免单租户耗尽资源	QueueSort、PriorityClass、Preemption、ResourceQuota、Kueue	公平 vs 吞吐
高可用（HA）	scheduler 自身故障不影响新 Pod 调度	Leader Election、多副本、--leader-elect-resource-name	故障切换时间 vs 一致性
用户可配置性	不同业务用不同调度策略	KubeSchedulerConfiguration、多 Profile、pluginConfig	配置灵活 vs 运维复杂度

面试用法：被问"K8s scheduler 的设计哲学是什么"先报六维，再用具体 Plugin 举例。

经典插件一：NodeAffinity（Required vs Preferred）

Node Affinity / Anti-Affinity 与 Pod Affinity / Anti-Affinity

这里有三组概念容易混：Node Affinity、Node Anti-Affinity、Pod Affinity / Pod Anti-Affinity。一句话区分：

Node Affinity / Anti-Affinity：Pod 和节点之间的关系。Pod Affinity / Anti-Affinity：Pod 和 Pod 之间的关系。

Node Affinity：Pod 对节点有偏好

Node Affinity 解决的是：这个 Pod 应该去什么样的机器上？它是比 nodeSelector 更强大的节点选择机制，支持软约束（preferred）和硬约束（required），以及基于节点标签的复杂表达式。

类型	行为	典型场景
requiredDuringSchedulingIgnoredDuringExecution	硬约束，Pod 必须调度到满足条件的节点，否则 Pending	必须是 A100 节点、必须在北京机房
preferredDuringSchedulingIgnoredDuringExecution	软约束，优先调度到满足条件的节点，但不强制	最好在 SSD 节点、最好在北京机房（但上海也可以）

IgnoredDuringExecution 的含义

调度时会检查这个规则；Pod 已经运行后，如果节点标签变化了，Kubernetes 默认不会因为这个规则再把 Pod 驱逐掉。这是设计选择：避免运行时驱逐造成服务中断。如果需要运行时驱逐，用 Taint 的 NoExecute 效果。

Node Anti-Affinity

Kubernetes 里严格说没有一个和 nodeAffinity 同级的字段叫 nodeAntiAffinity，但可以通过 nodeAffinity 里的 NotIn、DoesNotExist 等表达"不要去某些节点"。例如：不要调度到 V100 节点、不要调度到 spot 节点。

NodeAffinity 在两个扩展点上的不同行为

NodeAffinity 同时挂在 Filter（处理 Required）和 Score（处理 Preferred）两个扩展点上。这是"硬约束 vs 软偏好"在调度框架里的标准落地方式。

类型	字段	挂在哪个扩展点	不满足时的行为
Required	`requiredDuringSchedulingIgnoredDuringExecution`	PreFilter + Filter	节点直接被过滤掉，Pod Pending
Preferred	`preferredDuringSchedulingIgnoredDuringExecution`	PreScore + Score	节点得分降低，但仍可能被选中

Required 在 Filter 阶段的判断逻辑

// 简化版，pkg/scheduler/framework/plugins/nodeaffinity/node_affinity.go
func (pl *NodeAffinity) Filter(ctx context.Context, state *framework.CycleState,
    pod *v1.Pod, nodeInfo *framework.NodeInfo) *framework.Status {

    node := nodeInfo.Node()
    affinity := pod.Spec.Affinity

    // 没有 Required 约束 → 直接通过
    if affinity == nil || affinity.NodeAffinity == nil ||
       affinity.NodeAffinity.RequiredDuringSchedulingIgnoredDuringExecution == nil {
        return nil
    }

    // 把 Required 转成 NodeSelector，对 Node 求值
    selector, err := nodeaffinity.NewNodeSelector(
        affinity.NodeAffinity.RequiredDuringSchedulingIgnoredDuringExecution)
    if err != nil {
        return framework.NewStatus(framework.Error, err.Error())
    }
    if !selector.Match(node) {
        return framework.NewStatus(framework.UnschedulableAndUnresolvable,
            "node(s) didn't match Pod's node affinity/selector")
    }
    return nil
}

Preferred 在 Score 阶段的打分公式

Preferred 项每条带 weight（1-100）。一个节点的 NodeAffinity 得分等于它**满足的 preferredTerm 的 weight 之和**，再归一化到 0-100。

$$\text{NodeAffinityScore}(n) = \sum_{t \in \text{preferred terms}} w_t \cdot \mathbb{1}[\text{node } n \text{ matches term } t]$$

归一化（在 NormalizeScore 阶段）：

$$\text{Score}_{norm}(n) = \frac{\text{NodeAffinityScore}(n)}{\max_n \text{NodeAffinityScore}(n)} \cdot \text{MaxNodeScore}$$

其中 MaxNodeScore = 100。

Pod Affinity / Anti-Affinity：Pod 之间的关系

Pod Affinity 解决的是：这个 Pod 希望和哪些已有 Pod 放近一点？判断对象不是节点标签，而是已有 Pod 的标签。Pod Anti-Affinity 则相反：不希望和某些 Pod 放得太近。

类型	判断对象	典型场景
Pod Affinity	已有 Pod 的标签	训练任务靠近数据缓存 Pod（降低延迟）；Worker 靠近 Parameter Server
Pod Anti-Affinity	已有 Pod 的标签	同服务副本不要在同一节点（高可用）；两个大 GPU 任务不要在同一台机器（避免资源竞争）

topologyKey 是什么？

Pod Affinity / Anti-Affinity 中 topologyKey 表示"靠近"或"远离"是按什么范围来定义的：kubernetes.io/hostname 表示同一节点，topology.kubernetes.io/zone 表示同一可用区，rack 表示同一机架。

性能影响

Pod Affinity/Anti-Affinity 需要在调度时扫描大量 Pod，大规模集群中可能显著增加调度延迟。建议限制 topologyKey 的粒度，避免在超大集群中使用跨节点的 Pod Anti-Affinity。

Node Affinity 和 Pod Affinity 的区别（面试核心）

类型	判断对象	例子
Node Affinity	节点的标签	我要去 A100 节点
Node Anti-Affinity	节点的标签	我不要去 spot 节点
Pod Affinity	已有 Pod 的标签	我要靠近 redis Pod
Pod Anti-Affinity	已有 Pod 的标签	我不要和同服务副本在同一节点

一句话：Node Affinity 看节点标签，Pod Affinity 看已有 Pod 标签。硬约束（required）主要在 Filter 阶段起作用，不满足就直接过滤掉节点；软偏好（preferred）主要在 Score 阶段起作用，满足偏好的节点得分更高。

经典插件二：TaintToleration（三种 Effect 的语义差异）

Taint 打在节点上、Toleration 写在 Pod 上。Pod 必须容忍节点的所有 Taint 才能调度。

三种 Effect 的语义、扩展点和触发对象

Effect	语义	挂在哪个扩展点	对正在运行的 Pod 的影响	典型场景
`NoSchedule`	新 Pod 不容忍则不能调度到此节点	Filter	不影响（已运行的 Pod 留在节点上）	GPU 节点专用、节点池隔离
`PreferNoSchedule`	新 Pod 不容忍则尽量不调度，但不强制	Score（不是 Filter）	不影响	软隔离，例如"成本高的 spot 节点尽量后用"
`NoExecute`	新 Pod 不容忍则不能调度；运行中的 Pod 不容忍则被驱逐	Filter + 由 controller-manager 中的 TaintEvictionController 执行驱逐	会驱逐（可通过 `tolerationSeconds` 延迟）	节点不健康、维护前抢占清场

关键区分：NoSchedule 在 Filter，PreferNoSchedule 在 Score —— 所以 PreferNoSchedule 不会让节点出现在 FailedScheduling 事件里。NoExecute 是唯一一个**事后驱逐**的 effect。

容忍判断逻辑

Toleration 通过 operator 决定匹配方式：

Equal（默认）：要求 key、value、effect 都相等。
Exists：只要 key 存在即可（value 字段必须为空），常用于"容忍所有 NoSchedule"。

"通配容忍"模式：

# 容忍任意 NoSchedule taint
- operator: Exists
  effect: NoSchedule

# 容忍所有 effect 的所有 taint（很危险，仅 system pod 使用）
- operator: Exists

经典插件三：NodeResourcesFit（Filter + 三种打分策略）

Filter 阶段：装得下吗

NodeResourcesFit 在 Filter 阶段判断节点可用资源是否能装下 Pod 的 requests。逻辑很直接：对每个资源类型（CPU、Memory、扩展资源），检查 node.Allocatable - sum(running pods.requests) ≥ pod.requests。

Score 阶段：三种打分策略

NodeResourcesFit 在 Score 阶段支持三种策略，通过 scoringStrategy.type 配置。下面给出每种策略的打分公式。

1. LeastAllocated（默认）：剩余资源越多分越高

$$\text{Score}_{Least}(n) = \frac{\sum_i (\text{Allocatable}_i - \text{Requested}_i) \cdot w_i / \text{Allocatable}_i}{\sum_i w_i} \cdot \text{MaxNodeScore}$$

其中：

$i$ 遍历每种资源（CPU、Memory、扩展资源等）
$w_i$ 是该资源的权重（在 resources 中配置）
$\text{MaxNodeScore} = 100$

语义：把负载分散到资源最空闲的节点，适合通用场景。

2. MostAllocated：剩余资源越少分越高（装箱）

$$\text{Score}_{Most}(n) = \frac{\sum_i \text{Requested}_i \cdot w_i / \text{Allocatable}_i}{\sum_i w_i} \cdot \text{MaxNodeScore}$$

语义：把 Pod 集中到已经"快装满"的节点，腾出空节点用于大任务。适合 GPU 训练等需要整机资源的场景，避免碎片化。

3. RequestedToCapacityRatio：曲线打分

支持自定义"利用率 → 分数"的折线映射：

$$\text{Score}_{RTC}(n) = \frac{\sum_i \text{piecewise}(\text{Requested}_i / \text{Allocatable}_i) \cdot w_i}{\sum_i w_i}$$

其中 piecewise 由用户配置的 shape: [{utilization, score}, ...] 折线决定。例如：

scoringStrategy:
  type: RequestedToCapacityRatio
  resources:
    - name: nvidia.com/gpu
      weight: 5
  requestedToCapacityRatio:
    shape:
      - utilization: 0
        score: 0
      - utilization: 100
        score: 10

语义：表达"装到 80% 最优、再装会降速"这类非线性偏好。常用于"同时考虑装箱和性能拐点"的场景。

三种策略的选型

策略	典型场景	风险
LeastAllocated	通用业务、CPU/Memory 资源均匀打散	大 GPU 任务可能找不到整机资源
MostAllocated	GPU 训练集群、希望先装满旧节点再用新节点	单节点故障影响多个 Pod
RequestedToCapacityRatio	有明确性能拐点的场景，例如 GPU 利用率 ≥ 80% 后性能下降	配置复杂，需要持续 tune shape 曲线

Scheduler Extender（HTTP 扩展）

Extender 是什么、和 Plugin 的关系

Extender 是 K8s 早期的扩展机制，核心是一个独立 HTTP 服务，scheduler 在 Filter / Prioritize / Bind 等阶段通过 HTTP 调用它。

维度	Extender	Scheduling Framework Plugin
部署形态	独立 HTTP 服务	编译进 scheduler 二进制
调用开销	HTTP 网络调用（ms 级）	函数调用（μs 级）
访问 scheduler cache	不能	可以
支持的扩展点	Filter、Prioritize、Preempt、Bind	全部 12 个扩展点
语言	任意（HTTP 服务）	仅 Go
定位	历史兼容、跨语言简单扩展	新功能首选

Extender 的 HTTP 通信路径

scheduler 主流程（schedulingCycle）
   |
   |--- Filter 阶段（in-tree filters 跑完）
   |      |
   |      v
   |   POST {extenderURL}/filter
   |      Body: {Pod, Nodes, NodeNameToInfo}
   |      Response: {Nodes, FailedNodes, Error}
   |
   |--- Score 阶段（in-tree scores 跑完）
   |      |
   |      v
   |   POST {extenderURL}/prioritize
   |      Body: {Pod, Nodes}
   |      Response: [{Host, Score}, ...]
   |
   |--- Bind 阶段（如果 extender 配置了 bindVerb）
   |      |
   |      v
   |   POST {extenderURL}/bind
   |      Body: {PodName, PodNamespace, PodUID, Node}
   |      Response: {Error}

KubeSchedulerConfiguration 中配置 Extender

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
extenders:
  - urlPrefix: "http://gpu-extender.kube-system.svc:8080"
    filterVerb: "filter"
    prioritizeVerb: "prioritize"
    weight: 5
    enableHTTPS: false
    nodeCacheCapable: true     # extender 自己缓存 NodeInfo，scheduler 只传 NodeName
    managedResources:           # 只对包含这些资源的 Pod 调用 extender
      - name: "example.com/foo"
        ignoredByScheduler: true
    httpTimeout: 1s             # 超时强制返回，避免阻塞 schedulingCycle
    ignorable: false            # extender 故障时是否允许调度继续

面试要点：Extender 现在主要见于历史遗留系统。新需求一律推荐 Framework Plugin。如果一定要用 Extender，关键参数是 httpTimeout 和 ignorable，否则 Extender 故障会拖死整个 scheduler。

抢占（Preemption）的设计哲学

高优 Pod 调度失败 → PostFilter 触发抢占 → 找出最小代价的 victim 集合 → 标记 nominatedNodeName → 等待 victim 优雅退出 → 重新调度。

抢占体现的设计哲学

声明式：用户通过 PriorityClass 表达"重要程度"，不需要写抢占代码。
公平性：抢占只能"高优抢低优"，避免同优先级互抢；PDB 限制驱逐范围。
异步退出：设置 nominatedNodeName 后等待 victim graceful shutdown，而不是立刻杀掉，保证服务连续性。
可扩展性：抢占决策在 PostFilter 扩展点，自定义 Plugin 可以替换默认抢占逻辑（例如考虑 GPU checkpoint 新鲜度）。

关联模块

Scheduler 内部机制 · 调度路径与队列（09a）：六维矩阵中"效率优先"的具体落地。
Cache、扩展点与抢占（09b）：抢占的扩展点位置（PostFilter）。
自定义 Plugin 实战（09d）：Plugin 接口与 Extender 的对比。
扩展点设计差异（09e）：PreFilter/Filter/PreScore/Score 的设计哲学。

内容模块

Workload 与 Controller

进阶★☆☆⏱ 18 min

一句话结论

Workload Controller 的本质是 reconcile：持续把实际状态拉回期望状态。

复习定位

维度	内容
所属模块	Kubernetes 核心
章节类型	系统类
解决问题	围绕控制面、调度资源模型、Workload Controller、网络存储、安全多租户、排障和 AI Infra GPU/DRA 建立平台面试答案。
面试抓手	区分 Deployment/StatefulSet/Job/Operator 的边界。

Workload 与 Controller：声明式系统的核心。

Workload 解决“如何管理一组 Pod”，Controller 解决“如何让实际状态持续逼近期望状态”。面试中不要只背 Deployment、StatefulSet、DaemonSet、Job 的用途，还要讲清楚 Informer → WorkQueue → Reconcile → 更新 status 这条控制循环。

第一部分：Workload（管理 Pod 生命周期与副本形态）

Workload 这一部分回答“应该用哪种对象来管理 Pod”。先理解 Pod 生命周期和探针，再学习 Deployment、StatefulSet、DaemonSet、Job、CronJob 的选型边界，最后落到发布链路和 AI Infra 场景。

Pod 生命周期与探针

阶段/机制	含义	面试重点
Pending	Pod 已创建但还未全部容器运行	可能卡在调度、镜像、网络、存储、资源
Running	Pod 已绑定节点，至少一个容器运行或启动/重启中	Running 不代表业务 ready
Succeeded / Failed	所有容器正常退出或至少一个失败退出	Job/CronJob 重点关注退出码和重试策略
livenessProbe	判断容器是否需要重启	配置过激会导致反复重启
readinessProbe	判断 Pod 是否可接流量	失败会从 Service endpoints 移除
startupProbe	保护慢启动应用	启动成功前禁用 liveness/readiness 的失败影响

Workload 控制器选型

Workload 控制器的本质不是“换一种 Pod 写法”，而是把不同类型应用的生命周期管理模式固化下来。选型时不要先背名字，而要先问五个问题：这个任务是否长期运行？是否无状态？是否需要稳定身份和稳定存储？是否必须每个节点都运行？是否以完成为目标而不是持续服务？

控制器	核心语义	适合场景	不适合场景	面试追问
Deployment	维护一组可替换的无状态 Pod 副本	Web API、推理服务、网关、普通无状态 worker	需要稳定 Pod 名称、每个副本独立存储、严格启动顺序的服务	ReplicaSet、滚动发布、回滚、`maxSurge`/`maxUnavailable`
StatefulSet	维护有序、有稳定身份和稳定存储的 Pod 集合	数据库、ZooKeeper/etcd、Kafka、需要固定 ordinal 的训练/服务组件	副本完全等价、随便替换即可的无状态服务	Headless Service、PVC 模板、ordinal、有序扩缩容
DaemonSet	保证符合条件的每个 Node 上运行一个 Pod	日志采集、监控 agent、CNI、CSI node plugin、GPU/Device Plugin	只想运行固定副本数，或者只想对外提供水平扩缩容服务	节点新增自动补 Pod、nodeSelector/tolerations、滚动升级 agent
Job	运行到成功完成为止，关注完成数和失败重试	离线计算、一次性数据处理、模型转换、批量压测、训练前预处理	需要长期常驻、持续接流量的服务	`backoffLimit`、`parallelism`、`completions`、Indexed Job
CronJob	按时间周期创建 Job	定时清理、周期报表、定期 checkpoint 校验、定时数据同步	强实时任务、必须精确到秒且不能受控制面延迟影响的任务	`concurrencyPolicy`、`startingDeadlineSeconds`、历史保留

选型决策树：先看生命周期，再看身份和放置约束

问题	如果答案是 yes	通常选择	原因
任务是否只需要跑完一次或跑完 N 个分片？	是	Job	Job 关心成功完成、失败重试和并行完成数，而不是常驻副本
任务是否按固定周期触发？	是	CronJob	CronJob 负责按 schedule 创建 Job，并处理错过调度和并发策略
是否要求每个节点都运行一个组件？	是	DaemonSet	节点级 agent 的目标不是副本数，而是覆盖所有符合条件的节点
每个副本是否需要稳定网络身份或独立持久化存储？	是	StatefulSet	StatefulSet 提供稳定 Pod 名、ordinal、PVC 和有序生命周期
副本是否完全等价、可替换、可水平扩缩容？	是	Deployment	Deployment 最适合无状态服务滚动发布、扩缩容和回滚

一句话：Deployment 管“可替换副本”，StatefulSet 管“有身份副本”，DaemonSet 管“每节点一个”，Job 管“跑完即止”，CronJob 管“定时跑完”。

AI Infra 场景怎么选

场景	推荐控制器	为什么	容易踩坑
在线推理服务	Deployment	请求无状态，副本可替换，适合 HPA、滚动发布和回滚	如果有本地 KV cache / 模型 warmup，要用 readiness 控制接流量时机
每台 GPU 节点运行 device plugin	DaemonSet	需要覆盖所有 GPU 节点，并随节点加入自动部署	要配 nodeSelector、tolerations，避免部署到非 GPU 节点
NCCL benchmark / 模型转换 / 数据预处理	Job	目标是完成任务并退出，失败可按策略重试	不要用 Deployment 跑一次性任务，否则失败语义和完成语义不清楚
周期性清理 checkpoint 或生成资源报表	CronJob	按时间创建 Job，并控制并发和历史保留	要设置 `concurrencyPolicy`，避免上一次未完成时重复跑
带稳定身份的分布式存储或协调组件	StatefulSet	每个副本需要固定名称、固定存储和有序启动	不要把普通无状态服务强行做 StatefulSet，会增加运维复杂度
PyTorch/Volcano/Kubeflow 训练任务	通常不是原生 Deployment，而是 Job/CRD/Operator	训练需要 gang、角色、rank、状态机、失败恢复和队列准入	原生 Job 不理解训练语义；复杂训练通常要 TrainingJob / PyTorchJob / VolcanoJob

高频误区

误区 1：有多个副本就用 Deployment。如果副本有固定身份、固定磁盘或有序启动要求，应考虑 StatefulSet。
误区 2：跑一次的任务也用 Deployment。Deployment 追求长期副本数稳定，任务完成退出后会被重新拉起；一次性任务应该用 Job。
误区 3：定时任务直接在应用里 sleep 循环。CronJob 可以把调度、失败重试、历史保留和并发策略交给 Kubernetes 管理。
误区 4：DaemonSet 等于每台机器一定有一个 Pod。它只会在符合 nodeSelector、affinity、taints/tolerations 等条件的节点上创建 Pod。
误区 5：StatefulSet 自动解决数据一致性。StatefulSet 只提供稳定身份和存储，数据复制、选主、分片、故障恢复仍然是应用或 Operator 的职责。

Deployment 滚动发布链路

用户修改 Deployment template，例如镜像 tag。
Deployment Controller 发现 template hash 变化，创建新的 ReplicaSet。
按 maxSurge 增加新 Pod，按 maxUnavailable 减少旧 Pod。
新 Pod readiness 通过后才进入 Service endpoints，逐步承接流量。
旧 ReplicaSet 保留一定 revision，支持 kubectl rollout undo 回滚。

发布排障要看 Deployment condition、ReplicaSet、Pod events、readiness probe、镜像拉取和应用日志。

第二部分：Controller（让实际状态持续逼近期望状态）

Controller 这一部分回答“系统如何自动修正状态”。核心不是事件回调，而是基于 Informer 缓存、WorkQueue 和 Reconcile 循环，把用户声明的 spec 转换为实际资源，并把结果写回 status。

Controller Pattern：Informer、WorkQueue、Reconcile

组件	作用	为什么需要
Reflector	List/Watch API Server，把变化写入本地缓存	减少控制器直接打 API Server 的压力
Informer	维护对象缓存，并触发事件回调	让控制器以事件驱动方式工作
Indexer / Lister	按 namespace/name 或索引查询缓存	提高读取效率
WorkQueue	保存需要处理的对象 key，支持去重和限速	事件和业务处理解耦，失败可重试
Reconcile	读取当前状态，计算差异，执行修正动作	控制器的核心逻辑
Status / Conditions	对外暴露控制结果和阶段状态	便于用户和其他控制器观测

CRD / Operator：先把三个层次讲清楚

Operator = CRD + Controller + 领域运维逻辑。面试时不要只说“Operator 是自定义控制器”，而要把三层拆开：CRD 让 Kubernetes 认识一种新的资源类型；Controller 负责 watch 这种资源并不断 reconcile；Operator 在 reconcile 里放入某个领域的生命周期管理经验，例如训练任务启动、失败恢复、扩缩容、checkpoint 清理和状态回写。

层次	解决的问题	面试中要讲清楚
CRD	把领域对象注册成 Kubernetes API 资源	例如 `TrainingJob`、`RayCluster`、`InferenceService`，用户可以像操作 Pod 一样 `kubectl apply/get/describe`
Controller	持续把实际状态修正到期望状态	通过 Informer 监听事件，放入 WorkQueue，由 Reconcile 创建/更新/删除下游资源
Operator	把领域运维知识自动化	不仅创建 Pod，还要处理启动顺序、故障恢复、状态机、外部资源清理、升级和多租户策略

一句话理解

CRD 是“用户提交的订单格式”，Controller 是“订单处理流水线”，Operator 是“懂这个业务的自动运维机器人”。如果只是创建几个 Pod，那只是 Controller；如果它还理解训练任务什么时候算成功、失败后怎么重试、checkpoint 怎么清理、队列资源怎么释放，才更接近 Operator。

CRD 对象应该怎么设计：spec、status、conditions

CRD 设计的核心是把“用户想要什么”和“系统观察到什么”分开。spec 是用户声明的期望状态，status 是控制器观察和计算出的实际状态，conditions 是结构化阶段信息。这个边界如果混乱，Operator 很容易变成不可维护的脚本。

字段	应该放什么	不应该放什么	训练任务例子
`spec`	用户声明的期望状态	运行时变化、错误原因、Pod 实际 IP	镜像、启动命令、worker 数、GPU 数、队列、优先级、容错策略
`status`	系统观测到的实际状态	用户配置项	当前 phase、已创建 Pod 数、ready worker 数、最近一次失败原因、checkpoint 路径
`conditions`	可机器读取的状态条件	大段非结构化日志	`Admitted`、`PodsCreated`、`WorkersReady`、`Running`、`Failed`
`metadata.ownerReferences`	表达父子资源归属	跨 namespace 乱指向	Worker Pod、Service、ConfigMap 归属于 TrainingJob，TrainingJob 删除后级联回收
`metadata.finalizers`	删除前必须完成的外部清理	永远不移除的阻塞标记	释放队列占用、删除外部 checkpoint 临时目录、清理临时 Service/DNS 记录

面试高频追问

为什么 Controller 不应该随意改 spec？因为 spec 是用户意图，Controller 如果偷偷修改 spec，就会破坏声明式系统的可预测性。正确做法是：默认值通过 admission/defaulting 处理，运行时状态写入 status，异常原因写入 status.conditions。

Reconcile 到底在做什么：从“事件驱动”到“状态驱动”

Operator 不是收到一个事件就执行一次脚本，而是每次 reconcile 都重新读取当前世界，计算期望状态和实际状态的差异，然后执行最小修正动作。这样即使事件丢失、Controller 重启、Pod 被人工删除，也能最终恢复一致。

Reconcile 步骤	要做什么	TrainingJob 例子
1. 读取对象	从缓存/API Server 获取 CR 当前状态	读 TrainingJob 的 spec、status、deletionTimestamp
2. 处理删除	如果对象正在删除，执行 finalizer 清理	释放队列 quota、删除临时 checkpoint、移除 finalizer
3. 计算期望状态	根据 spec 推导应存在的下游资源	应该有 1 个 master Pod、N 个 worker Pod、Service、ConfigMap
4. 对比实际状态	检查下游资源是否缺失、过期、异常	发现 worker-3 被删了，或者镜像版本与 spec 不一致
5. 执行动作	只做必要的 create/update/delete	补 Pod、更新 ConfigMap、触发重试、暂停任务
6. 更新 status	把结果以结构化方式反馈给用户	写入 Running、Ready workers=7/8、LastError=NCCL timeout

AI 训练任务 Operator 如何设计：从 CRD 到训练状态机

训练任务 Operator 的关键不是“创建一堆 Pod”，而是把训练任务抽象成一个可恢复、可观测、可排队、可清理的状态机。它要同时理解 Kubernetes 资源、训练框架语义和调度系统边界。

1. TrainingJob spec

描述用户想要的训练任务：镜像、启动命令、worker 数、每个 worker 的 GPU/CPU/内存、数据路径、checkpoint 策略、队列、优先级、容错策略。

2. 下游 Kubernetes 资源

Operator 根据 spec 创建 Pod/StatefulSet、Service、ConfigMap、Secret、PVC，并通过 OwnerReference 建立归属关系。

3. 调度与准入

大规模训练不能直接创建一堆 Pod 抢资源。Operator 通常要和 Kueue、Volcano 或自研队列系统配合，等资源整体准入后再启动。

4. 状态与容错

Operator 通过 status.conditions 暴露 Pending、Admitted、PodsCreated、WorkersReady、Running、Restarting、Succeeded、Failed 等阶段。

状态	含义	Operator 动作	用户能看到什么
Pending	TrainingJob 已提交，但还没获得资源	创建队列对象或等待 quota/Gang 准入	等待原因、队列位置、资源缺口
Admitted	资源准入通过，可以创建训练资源	创建 Pod、Service、ConfigMap、Secret	已准入、开始拉起 worker
WorkersReady	训练所需 worker 已 ready	确认 rendezvous endpoint、写入启动配置	ready worker 数、master endpoint
Running	训练进程正在运行	持续观察 Pod、日志、退出码、checkpoint 心跳	训练运行时长、重启次数、最近 checkpoint
Restarting	部分 worker 失败，正在恢复	按策略重建 Pod、触发从 checkpoint 恢复或弹性缩容	失败原因、恢复进度、retry count
Succeeded / Failed	训练成功完成或不可恢复失败	写最终状态，按策略保留或清理资源	完成时间、失败原因、输出路径

AI 训练 Operator 的边界：不要和 Scheduler / Device Plugin 混在一起

这部分是面试官最常追问的地方。Operator、Scheduler Plugin、Device Plugin/DRA 都和 GPU 训练有关，但它们管的层次完全不同。答清楚边界，说明你真的理解 Kubernetes 扩展体系。

组件	它负责什么	不负责什么	训练场景例子
TrainingJob Operator	任务生命周期和业务编排	不决定具体 Pod 放到哪台机器	创建 worker Pod、写 status、失败恢复、清理 checkpoint 临时资源
Queue / Admission	任务是否允许进入集群消费资源	不负责单个 Pod 的节点打分	Kueue 判断队列 quota 是否足够，Volcano 判断 PodGroup 是否满足 minMember
Scheduler / Scheduler Plugin	Pod/PodGroup 放到哪些节点	不理解完整训练业务生命周期	Gang、拓扑感知、优先级、抢占、GPU/NVLink 亲和
Device Plugin / DRA	设备发现、上报和容器内设备交付	不决定训练任务状态机	把 GPU、MIG、RDMA 网卡暴露给 kubelet，并把设备挂进容器

面试口径：Operator 管“这个训练任务应该经历什么生命周期”，Scheduler 管“Pod 应该放在哪里”，Device Plugin/DRA 管“设备如何被发现并交付给容器”。

Kubebuilder 实战：从脚手架到第一个 Operator

前面的内容解决“Operator 是什么”，Kubebuilder 解决“怎么把它写出来”。Kubebuilder 的价值不是替你写业务逻辑，而是把项目骨架、CRD 生成、RBAC、Webhook、部署 YAML、测试目录这些重复工程化工作标准化。参考文章把完整流程拆成：初始化项目、创建 API、完善 CRD、实现 Controller、可选 Webhook、本地调试、构建镜像和部署清单。

步骤	命令 / 产物	你要真正理解什么
初始化项目	`kubebuilder init --domain example.com --repo github.com/xxx/operator`	`domain` 会参与 CRD group，例如 `training.ai.example.com`；`repo` 是 Go module 路径
创建 API	`kubebuilder create api --group core --version v1 --kind Application --namespaced=true`	这里本质是在定义一个 GVK：Group、Version、Kind；同时生成 API 类型、CRD 样例、Controller 骨架
完善类型	`api/v1/*_types.go`	在 Go struct 中定义 `Spec` 和 `Status`，再由 controller-gen 生成 CRD schema 和 deepcopy 代码
实现控制器	`internal/controller/*_controller.go`	核心不是写事件回调，而是在 `Reconcile` 中反复读取对象、处理删除、创建/更新下游资源、回写 status
生成清单	`make manifests`、`make install`	生成 CRD、RBAC、Webhook 等 YAML，并把 CRD 安装到集群
本地运行	`make run`	Controller 可在本地连远程 kubeconfig 调试，但 Webhook 调试通常需要额外处理证书和访问路径
部署上线	`IMG=xxx make docker-buildx`、`make build-installer`	把 Controller 打成镜像，并生成包含 CRD、RBAC、Deployment 的安装包

我的理解

Kubebuilder 不是一个“魔法框架”，它只是把 Kubernetes controller 的标准套路固化下来：API 类型放在 api/，控制循环放在 internal/controller/，部署资源放在 config/。真正体现能力的地方仍然是：你能否把业务对象建模成清晰的 spec/status，并写出幂等、可重试、可观测的 reconcile。

参考来源

本节实战流程参考了 K8s Operator 开发 Part1：快速上手 Kubebuilder，构建你的第一个 K8s Operator，并结合 AI 训练任务 Operator 场景做了重新组织和补充。

GVK / GVR：写 Operator 前必须分清的两个标识

CRD 注册进 API Server 之后，会同时涉及“这个对象是什么”和“我通过 REST 路径怎么访问它”。这就是 GVK 和 GVR 的区别。面试时如果能讲清这个点，说明你不是只会套 Kubebuilder 命令。

概念	组成	更常出现在哪里	例子
GVK	Group / Version / Kind	对象类型识别、Scheme 注册、Controller 处理对象	`training.ai.example.com / v1 / TrainingJob`
GVR	Group / Version / Resource	REST 访问、dynamic client、kubectl 资源路径	`training.ai.example.com / v1 / trainingjobs`
核心区别	Kind 是单数类型名，Resource 通常是复数资源名	GVK 偏“类型系统”，GVR 偏“API 访问路径”	`Kind=Pod`，`Resource=pods`

面试口径：GVK 用来说明“这是什么类型的对象”，GVR 用来说明“通过哪个 API 资源路径操作它”。Controller 代码里经常关心 GVK/Scheme，动态客户端和 RESTMapper 经常关心 GVR。

Reconcile 代码骨架：Application Demo 到 TrainingJob 的迁移

参考文章中的 Application Demo 很适合入门：用户提交一个 Application CR，里面包含 spec.image 和 spec.enabled；Controller 根据它创建、更新或删除 Deployment，并把 Deployment 是否 ready 写回 status.ready。把这个例子迁移到 AI 训练场景，就是把 Deployment 换成一组 role 化的 worker/master Pod、Service、ConfigMap、PVC、队列对象和状态机。

// 典型 Reconcile 思路，不是完整可运行代码
func Reconcile(ctx, req) {
  // 1. 根据 namespace/name 获取 CR；NotFound 通常说明对象已删除，直接返回
  job := getTrainingJob(req.NamespacedName)

  // 2. 处理 deletionTimestamp：如果正在删除，先跑 finalizer 清理外部资源
  if job.IsDeleting() {
    cleanupQueueQuota(job)
    cleanupTemporaryCheckpoint(job)
    removeFinalizer(job)
    return
  }

  // 3. 确保 finalizer 存在，保证后续删除前有机会清理外部资源
  ensureFinalizer(job)

  // 4. 根据 spec 计算期望资源：Pod/Service/ConfigMap/PVC/PodGroup 或 Workload
  desired := buildDesiredTrainingResources(job.Spec)

  // 5. 对比实际状态，只做必要的 create/update/delete
  syncOwnedResources(desired)

  // 6. 观察下游资源状态，回写 status.conditions
  updateTrainingJobStatus(job)
}

Application Demo	TrainingJob Operator	设计变化
`spec.image`	镜像、启动命令、role、GPU 数、数据路径	从单应用部署变成分布式训练拓扑
`spec.enabled`	队列准入、暂停/恢复、重试策略	是否运行不只是布尔值，还要受 quota、Gang、优先级影响
Deployment ready	Master/Worker ready、Rendezvous、Checkpoint 心跳	训练任务 ready 需要结合框架语义
`status.ready`	`status.phase` + `conditions` + replica 统计 + last error	状态要能支持排障，而不是只有 true/false

Webhook：把默认值和校验前移到 Admission 阶段

Operator 里经常有两类逻辑不要放到 Reconcile 里硬兜底：一类是默认值，一类是非法输入校验。Kubebuilder 可以生成 Webhook 骨架，常见命令是 kubebuilder create webhook --group core --version v1 --kind Application --defaulting --programmatic-validation。

Webhook 类型	作用	Application 例子	TrainingJob 例子
Mutating Admission Webhook	给对象补默认值或注入字段	没有写 `enabled` 时默认设为 true	默认 restartPolicy、backoffLimit、checkpoint interval、priorityClass
Validating Admission Webhook	拒绝非法对象	校验 `spec.image` 格式	校验 GPU 数必须大于 0，worker 数和并行策略匹配，队列名合法
Reconcile	处理运行时状态收敛	创建或删除 Deployment	创建训练资源、等待准入、失败恢复、写 status

我的思考

Webhook 和 Reconcile 的边界要清楚：Webhook 负责“对象能不能进入系统、进入前补什么默认值”，Reconcile 负责“对象已经进入系统后，如何让实际状态收敛”。不要依赖 Reconcile 才发现明显非法的 spec，否则用户会看到对象创建成功但长期失败；也不要在 Webhook 里做耗时外部调用，否则会拖慢 API Server 的写路径。

从 Kubebuilder 到生产级 Operator：面试应该主动补充什么

文章中的流程能帮助你快速跑通第一个 Operator，但面试官通常会继续问“生产环境怎么做”。你需要主动补上工程化、稳定性和可观测性维度。

维度	入门 Demo 常见做法	生产级思考
幂等性	看到事件就创建资源	每次 reconcile 都先读实际状态，已存在则比较差异，避免重复创建和重复副作用
OwnerReference	只创建子资源	给 Pod/Service/ConfigMap 设置 owner，利用 Kubernetes GC 自动清理内部资源
Finalizer	可能不处理删除	清理外部队列占用、对象存储临时目录、实验追踪记录；清理逻辑必须可重试、可超时
Status Conflict	直接 update status	处理 resourceVersion 冲突，必要时重试；用 `observedGeneration` 表示 status 对应哪一版 spec
权限	给较大的 RBAC	按最小权限生成和审查 RBAC，避免 Controller 具备不必要的集群级权限
可观测性	只看日志	补充 events、conditions、metrics、trace id、reconcile latency、queue depth、error rate
升级兼容	只有一个版本	考虑 CRD versioning、conversion webhook、字段废弃策略和向后兼容

面试口径：Kubebuilder 帮你生成 Operator 的工程骨架，生产级 Operator 的关键是 API 设计、幂等 Reconcile、删除清理、状态可观测、权限最小化和版本演进。

Q: 如果让你现场设计一个 TrainingJob CRD，你会包含哪些字段？

核心 spec

至少包括：镜像、启动命令、replica/role 定义、每个 role 的资源请求、队列名、优先级、重试次数、checkpoint 配置、数据输入输出路径、环境变量和 Secret 引用。

核心 status

至少包括：phase、conditions、readyReplicas、activeReplicas、failedReplicas、startTime、completionTime、lastCheckpoint、lastFailureReason、observedGeneration。

设计原则

spec 表达用户意图，status 表达系统事实；不要把运行时状态塞回 spec，也不要让用户通过改 status 控制系统。

面试口径：TrainingJob CRD 的设计重点是 role 化资源声明、队列准入、容错恢复和可观测状态，而不是简单包一层 PodTemplate。

Q: TrainingJob Operator 如何处理删除？为什么需要 Finalizer？

为什么需要

OwnerReference 只能清理 Kubernetes 内部子资源，但训练任务可能还占着外部系统资源，例如队列占用、临时 checkpoint、对象存储目录、外部 DNS/Service 注册、实验追踪记录。

删除流程

用户删除 TrainingJob 后，对象先进入 deletionTimestamp 状态；Operator 看到后执行外部清理；清理成功后移除 finalizer；API Server 最终真正删除对象。

常见坑

如果清理逻辑失败但 finalizer 不移除，对象会一直 Terminating；所以 finalizer 逻辑必须幂等、可重试、可超时，并能把失败原因写入 status/events。

面试口径：Finalizer 是删除前的外部资源清理协议，关键是幂等、可重试和失败可观测。

Workload 与 Controller 高频问答

本模块的问答按“概念 → 作用 → 链路/排查 → 面试口径”组织，避免只背一段结论。

Q: Deployment 和 StatefulSet 有什么区别？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. Deployment 的定位

Deployment 面向无状态服务，重点是副本数、滚动发布、回滚和通过 Service 做负载均衡。

2. StatefulSet 的定位

StatefulSet 面向有状态服务，提供稳定序号、稳定网络身份和稳定 PVC，Pod 通常按顺序创建、更新和删除。

3. 存储与网络差异

Deployment 的 Pod 名称和挂载存储通常不稳定；StatefulSet 常配 Headless Service 和 volumeClaimTemplates，让每个副本有固定身份。

4. 适用场景

Web 服务、无状态 API 适合 Deployment；数据库、消息队列、需要固定 rank/身份的训练组件更适合 StatefulSet。

面试口径：Deployment 管无状态弹性副本，StatefulSet 管有状态、有序、稳定身份和稳定存储的副本。

Q: Informer 为什么重要？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 概念

Informer 是 controller-runtime/client-go 中的 List/Watch 缓存机制，会把 API Server 中的对象变化同步到本地缓存。

2. 作用

它减少 controller 直接频繁访问 API Server 的压力，并把对象变化转成事件回调。

3. 和 WorkQueue 的关系

Informer 收到事件后通常只入队 namespace/name key，真正业务逻辑由 worker 从 WorkQueue 取出后 reconcile。

4. 生产价值

本地缓存、事件驱动、失败重试、限速和去重，是 Kubernetes controller 能大规模运行的基础。

面试口径：Informer 负责高效 watch 和缓存对象，WorkQueue 负责解耦事件与处理，Reconcile 负责把实际状态修正到期望状态。

Q: 为什么 Controller 不直接 watch 后立刻处理对象，而要放 WorkQueue？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 解耦事件与处理

watch 回调应该尽快返回，避免业务处理阻塞事件接收，WorkQueue 把“收到事件”和“处理对象”拆开。

2. 去重

同一个对象短时间多次变化时，队列可以合并 key，避免重复处理。

3. 限速与重试

处理失败可以重新入队并退避，避免 tight loop 打爆 API Server 或外部系统。

4. 并发控制

多个 worker 可以并发消费队列，同时保持同一对象按 key 维度可控处理。

面试口径：WorkQueue 是 controller 的缓冲层，解决去重、限速、失败重试和并发控制。

Q: Operator 和普通 Controller 有什么区别？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 共同点

二者都基于 watch、queue、reconcile 模式，持续把实际状态逼近期望状态。

2. Operator 的特点

Operator 通常包含 CRD 和领域运维逻辑，不只是管理原生资源，还把数据库、训练任务、推理服务等运维知识编码进去。

3. 作用

它能自动处理部署、扩缩容、备份、故障切换、版本升级、状态回写等复杂生命周期。

4. 边界

Operator 负责编排和生命周期，不应该替代 scheduler 做底层放置决策，也不应该替代 Device Plugin/DRA 做设备发现交付。

面试口径：Controller 是控制模式，Operator 是“CRD + Controller + 领域运维知识”的产品化控制器。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

内容模块

网络与存储

进阶★★☆⏱ 18 min

一句话结论

K8S 网络和存储解决 Pod 如何被访问、如何发现服务、如何挂载持久数据。

复习定位

维度	内容
所属模块	Kubernetes 核心
章节类型	系统类
解决问题	围绕控制面、调度资源模型、Workload Controller、网络存储、安全多租户、排障和 AI Infra GPU/DRA 建立平台面试答案。
面试抓手	按 CNI、Service、DNS、Ingress、PV/PVC/CSI 讲。

网络与存储：Pod 能不能被访问，数据能不能挂上

网络和存储经常一起出现在排障题里。Pod 启动不仅要调度成功，还要 CNI 分配网络、CSI 挂载卷；服务访问不仅要 Pod Running，还要 readiness、EndpointSlice、Service 转发和 DNS 都正常。

Kubernetes 网络模型

对象/机制	作用	面试重点
Pod IP	每个 Pod 一个可路由 IP	同集群 Pod 可直接通信，具体由 CNI 实现
CNI	为 Pod 配网、分配 IP、配置路由/隧道/策略	Calico、Cilium、Flannel 等实现差异
Service	为一组 Pod 提供稳定访问入口	通过 selector 关联 endpoints
EndpointSlice	保存 Service 后端 Pod 地址	替代老 Endpoints，更适合大规模
kube-proxy	实现 Service VIP 到后端 Pod 的转发	iptables、IPVS 模式
eBPF datapath	替代或增强 kube-proxy 的数据面	性能、可观测性、网络策略
CoreDNS	集群 DNS 解析	Service DNS、Headless DNS、外部解析

Service 类型与访问路径

类型	作用	典型场景	追问点
ClusterIP	集群内虚拟 IP	内部服务访问	VIP 如何转发到 Pod
NodePort	在每个节点暴露端口	简单外部访问或 LB 后端	端口范围、流量路径
LoadBalancer	对接云厂商/负载均衡器	生产外部入口	云控制器如何创建 LB
ExternalName	返回外部 DNS CNAME	集群内引用外部服务	不创建 ClusterIP 和 endpoints
Headless	`clusterIP: None`，直接返回后端 Pod DNS	StatefulSet、服务发现、自定义负载均衡	和 ClusterIP 的核心区别

Service 不通排查链路

看客户端访问的是 DNS、ClusterIP、NodePort 还是外部 LB。
检查 Service selector 是否匹配 Pod label。
检查 EndpointSlice 是否有 ready endpoints。
检查 Pod readinessProbe 是否失败。
进入 Pod 直接访问目标 Pod IP 和端口，区分应用问题与 Service 问题。
检查 NetworkPolicy、CNI、kube-proxy/eBPF 数据面、节点路由和安全组。
检查 CoreDNS 解析是否正常。

PV / PVC / StorageClass / CSI

对象/组件	职责	面试重点
PV	集群中的实际存储资源	容量、访问模式、回收策略
PVC	用户对存储的声明	像 Pod 申请 CPU 一样申请存储
StorageClass	动态供给模板	provisioner、parameters、reclaimPolicy、volumeBindingMode
CSI Controller	创建/删除/扩容卷、Attach/Detach	通常在控制面或独立 Deployment
CSI Node	节点侧 mount/unmount	通常是 DaemonSet
kubelet Volume Manager	在 Pod 启动前准备 volume	Pod 卡 ContainerCreating 常看这里

PV/PVC 绑定与 WaitForFirstConsumer

普通动态供给可能在 Pod 调度前就创建卷，但对本地盘、可用区相关云盘等存储，提前创建可能导致卷所在拓扑和 Pod 调度节点不一致。WaitForFirstConsumer 会延迟卷绑定和创建，等 scheduler 结合 Pod 约束和存储拓扑一起决策。

模式	行为	适合场景
Immediate	PVC 创建后立即绑定/供给 PV	无拓扑限制或共享存储
WaitForFirstConsumer	等第一个 Pod 使用 PVC 时再结合调度创建/绑定	本地盘、云盘可用区、拓扑敏感存储
StatefulSet volumeClaimTemplates	为每个 Pod 自动创建独立 PVC	数据库、消息队列、有状态训练组件

Ingress / Gateway API：南北向流量入口的两代演进

Service 解决“集群内部怎么访问 Pod”，Ingress / Gateway API 解决“集群外部怎么进来”。Ingress 是 v1 时代的入口对象，能力相对单一（HTTP host/path 路由）；Gateway API 是社区推出的新一代标准，把入口拆成 GatewayClass / Gateway / *Route 三层，把基础设施权限和应用路由权限分开。

对象	作用	谁来管	面试关注点
IngressClass	声明集群里有哪种 Ingress 控制器	平台/集群管理员	支持多套 Ingress 共存（Nginx、Traefik、云厂商 LB）
Ingress	HTTP/HTTPS host + path 路由 → Service	应用方	能力有限，rewrite/auth/重试常靠 annotation 扩展
GatewayClass	声明一类 Gateway 实现	实现方/平台	类似 StorageClass，定义“某种网关”的能力
Gateway	实际监听的入口（IP、端口、TLS）	平台	把基础设施配置和路由配置解耦
HTTPRoute / TCPRoute / GRPCRoute	路由规则	应用方	支持 host、path、header、weight、mirror、timeout、retry
ReferenceGrant	跨 namespace 引用授权	资源所有者	解决多租户下 Route 引用别 namespace 的 Service 问题

面试口径：Ingress 是入口对象的“第一代”，Gateway API 把网关基础设施和应用路由解耦，更适合多租户和复杂流量治理。生产上常见的入口实现有 Nginx Ingress、Traefik、Istio Gateway、Envoy Gateway、云厂商 ALB。

NetworkPolicy：默认全通，加策略变隔离

Kubernetes 默认网络是“同 Pod、同 Namespace、跨 Namespace 全部互通”。NetworkPolicy 是 namespace 级的网络策略对象，用于定义“哪些 Pod 可以访问哪些 Pod、哪些端口”。它由 CNI 实现真正落地，CNI 不支持就形同虚设。

关键字段	作用	常见坑
`podSelector`	选中要被保护的目标 Pod	空 selector 表示选中 namespace 全部 Pod
`policyTypes: [Ingress, Egress]`	声明这条策略管入向、出向，还是两个都管	没列出的方向就不会被这条策略限制
`ingress.from / egress.to`	允许的来源/目标	支持 podSelector、namespaceSelector、ipBlock
`ports`	允许的端口和协议	不写代表所有端口都放行
“默认拒绝”模式	用一条空规则的策略实现 deny-all	常见做法：先 deny-all，再按需开放

能力	NetworkPolicy v1	AdminNetworkPolicy（社区演进）
作用域	单 namespace	集群级，平台管理员视角
动作	仅 allow	支持 allow / deny / pass，有优先级
表达 L7	不支持	需要 CNI（如 Cilium）扩展
典型用途	业务 namespace 自治	平台基线（例如禁止访问元数据服务）

面试常追问

“写了 NetworkPolicy 但不生效？”九成是 CNI 没启用 NetworkPolicy 实现（Flannel 默认没有）；剩下情况是 selector 写错、policyTypes 没写 Egress 导致出向没限制、或者忘了 DNS（CoreDNS 53/UDP）也要放行。

CNI 实现对比：Flannel / Calico / Cilium

CNI 是 Pod 网络的实现层，决定 Pod IP 怎么分、跨节点流量怎么走、NetworkPolicy 怎么落地。面试不要只说“我们用了 Calico”，要能说清三种主流实现的差异。

维度	Flannel	Calico	Cilium
跨节点数据面	VXLAN / host-gw（默认 overlay）	BGP（underlay 路由）或 VXLAN/IPIP	VXLAN / Geneve / native routing，可走 eBPF
NetworkPolicy	不原生支持，需要外挂	原生支持 + GlobalNetworkPolicy	原生支持 + L7（HTTP/gRPC/Kafka）
kube-proxy 替代	否	否（可选 eBPF 模式）	可完全替代 kube-proxy
可观测性	弱	中	强（Hubble，eBPF 流量级可视化）
典型适用	简单集群、入门	多租户、企业生产	大规模、需要 L7 策略和深度可观测

面试口径：Flannel 简单但策略弱；Calico 偏路由协议（BGP）+ 原生 NetworkPolicy；Cilium 走 eBPF，能替换 kube-proxy 并提供 L7 策略和 Hubble 可观测性。

kube-proxy 三种模式：iptables / IPVS / eBPF

Service VIP 到后端 Pod 的转发由 kube-proxy（或 CNI 替代实现）完成。三种模式在性能、规则规模和可观测性上差异明显。

维度	iptables	IPVS	eBPF（Cilium / Calico）
转发原理	通过 NAT 链做 DNAT/SNAT	内核 IPVS 模块做四层负载均衡	eBPF 程序挂在 socket / tc / XDP
规则数量	O(N)，Service 多了 iptables 规则线性膨胀	哈希表 O(1) 查找	map O(1)，且不依赖 iptables
大集群表现	10k+ Service 时同步慢、CPU 高	明显优于 iptables	最佳，且支持精细可观测
负载均衡算法	随机/轮询有限	rr / lc / sh / dh 等多种	由 eBPF 程序定义
排查工具	`iptables -t nat -L`	`ipvsadm -ln`	`cilium service list` / Hubble
conntrack 依赖	强依赖	仍依赖	可绕过 conntrack（提升性能）

面试口径

大集群（数千 Service / 数万 Pod）必须放弃 iptables 模式，要么 IPVS，要么 eBPF。eBPF 还能解决 conntrack 表打满的稳定性问题，并提供 L7 可观测能力。

CoreDNS 与集群 DNS 解析链路

Pod 里 nslookup my-svc 能拿到 IP，背后是 kubelet → /etc/resolv.conf → CoreDNS → API Server endpoint 缓存这条链。面试常考 ndots、search domain 和 NodeLocal DNSCache。

机制	作用	面试要点
ClusterFirst DNS 策略	Pod 默认把 CoreDNS 作为上游	kubelet 把 CoreDNS Service IP 写进 `/etc/resolv.conf`
`ndots: 5`	少于 5 个点的域名会先按 search 列表补全	访问外网域名性能差时，降低 ndots 或写 FQDN（结尾加点）
search domain	例如 `<ns>.svc.cluster.local svc.cluster.local cluster.local`	解释为什么 `my-svc` 能被解析为 `my-svc.<ns>.svc.cluster.local`
Headless DNS	返回 A 记录列表，每个 Pod 一条	StatefulSet `pod-0.svc.ns.svc.cluster.local` 也是这个机制
NodeLocal DNSCache	每个节点起一个本地缓存代理	避免 conntrack 表泄漏、CoreDNS 抖动放大；大集群必备
CoreDNS plugin chain	kubernetes / forward / cache / log / autopath	解析慢通常先看 forward 上游和 cache 命中率

ConfigMap / Secret 挂载到 Pod

ConfigMap 和 Secret 是 Pod 拿配置的标准方式。挂载方式决定它们是只读还是支持热更新，也决定排障路径。

挂载方式	是否热更新	使用场景
environment variables	否（Pod 重建才变）	启动参数、简单配置
volumeMount（projected / configMap / secret 卷）	是，kubelet 周期同步（默认约 60s）	大段配置文件，希望支持热更新
subPath 单文件挂载	否，subPath 不会更新	挂某一个文件到固定路径
immutable: true	不可变	大规模集群减少 watch 开销，避免误改

面试口径：env 不热更，volume 挂载会热更（除 subPath），Secret 默认只是 base64 不是加密，真正加密要靠 etcd encryption at rest 或外部 Secret 系统。

AI 训练场景的网络扩展：RDMA / Multus / SR-IOV / hostNetwork

大模型训练对网络带宽和延迟非常敏感（AllReduce、参数同步），仅靠默认 CNI 的 overlay 网络往往不够。AI Infra 集群常见的扩展方式：

方案	解决什么问题	典型用法	面试关注点
hostNetwork	Pod 直接用宿主机网络栈，零开销	NCCL 直连场景、节点级 agent	端口冲突、不安全、不能再走 Service 网格
Multus	给一个 Pod 接多张网卡	主网卡走默认 CNI，副网卡走 RDMA / 存储网	NetworkAttachmentDefinition 是它的核心 CRD
SR-IOV CNI	把物理网卡的 VF 直通给 Pod	RDMA、低延迟交易、NFV	每个 VF 是独立的网卡，绕过软件交换
RDMA shared device plugin	把 RDMA 设备暴露成扩展资源	`rdma/hca: 1`	调度时按 RDMA 设备亲和（同 NIC、同 NUMA）
InfiniBand / RoCE	低延迟集合通信链路	NCCL over IB、GPUDirect RDMA	需要拓扑感知调度，避免跨 leaf/spine 通信

面试口径

训练 Pod 通常长这样：用 Multus 同时挂主 CNI 网卡（控制面、Service 访问）和一张 RDMA 网卡（GPU 间集合通信）；调度器还要保证同一训练任务的 Pod 落在同一 leaf switch 下，否则 AllReduce 会跨 spine，性能腰斩。

网络与存储高频问答

本模块的问答按“概念 → 作用 → 链路/排查 → 面试口径”组织，避免只背一段结论。

Q: Service 不通怎么排查？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 确认访问入口

先确认客户端访问的是 DNS、ClusterIP、NodePort、LoadBalancer 还是 Ingress，不同入口对应不同链路。

2. 检查 Service 到 Pod 的映射

看 Service selector 是否匹配 Pod labels，再看 EndpointSlice 是否生成 ready endpoints。没有 endpoints 通常是 selector、readiness 或 Pod 状态问题。

3. 区分应用和 Service 问题

直接访问 Pod IP:Port，如果 Pod IP 不通，多半是应用、端口、容器或 CNI 问题；如果 Pod IP 通但 Service 不通，再看 kube-proxy/eBPF。

4. 检查网络基础设施

继续排查 CoreDNS、NetworkPolicy、CNI、kube-proxy/IPVS/iptables/eBPF、节点路由、安全组和云 LB。

面试口径：Service 不通按“入口 → selector/endpoints → Pod 直连 → DNS/策略/数据面”逐层缩小范围。

Q: Headless Service 和 ClusterIP Service 的区别？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. ClusterIP 的概念

ClusterIP Service 会分配一个虚拟 IP，客户端访问 VIP 后由 kube-proxy、IPVS 或 eBPF 转发到后端 Pod。

2. Headless 的概念

Headless Service 设置 clusterIP: None，不提供 VIP，DNS 直接返回后端 Pod IP 或稳定域名。

3. 作用差异

ClusterIP 适合普通服务负载均衡；Headless 适合客户端自己做负载均衡、服务发现或需要感知每个副本身份的场景。

4. 典型场景

StatefulSet 常配 Headless Service，让 pod-0.service.namespace.svc 这类稳定域名指向固定副本。

面试口径：ClusterIP 提供稳定 VIP 和服务转发，Headless 不提供 VIP，而是通过 DNS 暴露后端 Pod 地址。

Q: Ingress 和 Gateway API 有什么区别？什么时候选哪个？

回答思路：先说能力差异，再讲谁来管，最后给场景建议。

1. 模型差异

Ingress 把入口 IP、TLS、host/path 路由全塞在一个对象里；Gateway API 拆成 GatewayClass / Gateway / *Route 三层，平台管 Gateway，应用管 Route。

2. 能力差异

Ingress 主要支持 HTTP host/path，复杂能力（rewrite、auth、重试、流量切分）多靠 annotation 扩展，跨实现不通用。Gateway API 把 header 匹配、加权切分、mirror、timeout、retry 写进了标准字段。

3. 多协议

Gateway API 同时定义了 HTTPRoute / TCPRoute / TLSRoute / GRPCRoute，原生支持四层转发，Ingress 一般只管七层。

4. 选型建议

新建集群、需要多租户和精细流量治理优先 Gateway API；已有大量 Ingress 的存量集群，迁移要看 Ingress 控制器是否同时支持 Gateway API。

面试口径：Ingress 是入口对象第一代，Gateway API 是把基础设施和应用路由解耦的新一代标准，多租户和复杂流量治理场景更适合 Gateway API。

Q: Ingress Controller 和 Service Mesh 有什么区别？

Ingress Controller 主要解决南北向入口流量：外部 HTTP/HTTPS 请求如何根据 host/path 进入集群并路由到 Service。Service Mesh 主要解决东西向服务间通信治理：mTLS、重试、超时、熔断、流量拆分、可观测性和零信任。

维度	Ingress Controller	Service Mesh
主要流量方向	外部 → 集群	服务 ↔ 服务
核心能力	入口路由、TLS 终止、host/path 转发	mTLS、流量治理、熔断、重试、可观测性
典型实现	Nginx、Traefik、HAProxy、Envoy Gateway	Istio、Linkerd、Consul Connect

面试口径：Ingress 管入口，Service Mesh 管服务间治理；两者可以共存，不是简单替代关系。

Q: 写了 NetworkPolicy 但没生效，怎么排查？

回答思路：从 CNI 是否支持开始往下找，依次看 selector、方向、DNS。

1. 先确认 CNI 支持

NetworkPolicy 是规范，由 CNI 落地。Flannel 默认没有实现，需要换 Calico / Cilium 或加上 NetworkPolicy 控制器。kubectl get networkpolicy 能创建不代表能生效。

2. 检查 selector

看 podSelector 是否真的匹配目标 Pod 的 label，再看 ingress.from / egress.to 是否正确选中了允许的来源/目标。

3. 检查 policyTypes

没显式列出 Egress，出向就不会被这条策略限制。要拒绝出向必须把 Egress 写进 policyTypes。

4. 不要忘了 DNS

限制出向时常见坑：忘了放行 CoreDNS 53/UDP，导致业务起来直接解析失败，看起来像“NetworkPolicy 把所有访问都断了”。

面试口径：NetworkPolicy 不生效先看 CNI、selector、policyTypes，再看 DNS 是否被一起切断。

Q: 大集群（10k+ Service）为什么必须放弃 iptables 模式？

回答思路：从 iptables 的复杂度问题讲起，再讲 IPVS / eBPF 的优势。

1. iptables 的本质问题

每个 Service 在 iptables 里都是 O(N) 条规则，规则之间是线性匹配，链长后查找慢；同步全量 iptables 也是 O(N²) 规模操作。

2. 表现症状

Service 数量上万后，kube-proxy 单次 sync 数秒到数十秒，CPU 高，新 Service 生效慢，节点 iptables 大到影响内核报文路径性能。

3. IPVS

用内核 IPVS 做四层 LB，O(1) 哈希查找，规则数量与 Service 数解耦，并提供更多负载均衡算法。

4. eBPF

Cilium / Calico eBPF 模式可完全替代 kube-proxy，绕开 iptables/conntrack，提供 L7 可观测和更低延迟，更适合超大规模和高性能场景。

面试口径：大集群必须切到 IPVS 或 eBPF，iptables 的线性规则在 Service 上万后会同时拖慢控制面（同步）和数据面（查找）。

Q: ConfigMap / Secret 改了之后 Pod 为什么没更新？

回答思路：先区分挂载方式，再讲热更新机制和延迟。

1. 看挂载方式

用 env 注入的不会热更，必须重启 Pod；用 volume 挂载的（projected / configMap / secret 卷）会热更。

2. subPath 是个大坑

subPath 单文件挂载不支持热更新，用了 subPath 就只能重建 Pod 才能拿到新内容。

3. 同步周期

kubelet 默认每 ~60s 同步一次（受 configMapAndSecretChangeDetectionStrategy 影响），所以热更新不是即时，可能有分钟级延迟。

4. 应用是否监听文件变化

就算 kubelet 把文件刷新了，应用本身不重读配置也没用，常见做法是 SIGHUP、inotify 或定期 reload。

面试口径：env 注入不热更，volume 挂载会热更但有分钟级延迟，subPath 不会热更，最终生效还要看应用是否重新读取配置。

Q: 训练任务用 hostNetwork 还是 Multus + RDMA？怎么权衡？

回答思路：先讲两种方案各自的能力，再讲它们的代价。

1. hostNetwork 的优势

Pod 直接用宿主机网络栈，没有 overlay 开销，最低延迟，最简单；NCCL 跨节点通信、节点级 agent 经常这样用。

2. hostNetwork 的代价

同节点端口冲突、不能再走 Service 网格 / NetworkPolicy / Sidecar 注入，安全性差，多租户场景几乎不可用。

3. Multus + RDMA / SR-IOV

Pod 主网卡走默认 CNI（控制面 / Service 访问），副网卡接入 RDMA / 存储网，AllReduce 走专用低延迟网络，控制面安全模型保留。

4. 还要看拓扑

不管哪种方案，调度器都要保证训练 Pod 落在同一 leaf 下，否则 AllReduce 跨 spine 会让带宽腰斩；这是 Topology-aware 调度和 DRA attributes 要解决的问题。

面试口径：单机训练 / 节点级 agent 可以 hostNetwork；多租户 + 大规模训练用 Multus 给 Pod 接 RDMA 副网卡，并配合拓扑感知调度。

Q: PVC 一直 Pending 怎么排查？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 先看 PVC 事件

用 kubectl describe pvc 看 Events，确认是 StorageClass 不存在、provisioner 异常、容量不足还是访问模式不匹配。

2. 检查 StorageClass

看 provisioner、parameters、reclaimPolicy、allowVolumeExpansion 和 volumeBindingMode。

3. 理解 WaitForFirstConsumer

如果是 WaitForFirstConsumer，PVC 可能会等使用它的 Pod 参与调度后才绑定或创建 PV。

4. 检查底层和拓扑

云盘、本地盘要看可用区、节点拓扑、配额、权限、CSI Controller/Node 组件和底层存储状态。

面试口径：PVC Pending 按“PVC Events → StorageClass/CSI → WaitForFirstConsumer → Pod 调度拓扑 → 底层存储”排查。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

内容模块

安全、准入与多租户

进阶★★☆⏱ 15 min

一句话结论

安全和多租户要从身份、授权、准入、隔离、配额和审计六层看。

复习定位

维度	内容
所属模块	Kubernetes 核心
章节类型	系统类
解决问题	围绕控制面、调度资源模型、Workload Controller、网络存储、安全多租户、排障和 AI Infra GPU/DRA 建立平台面试答案。
面试抓手	不要把 RBAC、Admission、Pod Security 混为一谈。

安全、准入与多租户：请求能不能进入，资源能不能隔离

Kubernetes 安全链路可以概括为：Authentication 识别你是谁，Authorization 判断你能做什么，Admission 决定这个请求是否符合集群策略，Persistence 才会写入 etcd。多租户治理则在此基础上叠加 namespace、RBAC、Quota、LimitRange、Pod Security、PriorityClass 和队列配额。

API Server 请求链路

阶段	作用	常见机制	面试重点
Authentication	确认调用者身份	证书、Token、OIDC、ServiceAccount	未认证通常是 anonymous 或直接拒绝
Authorization	判断是否有权限	RBAC、Node、Webhook	RBAC 是 allow-only，没有显式 deny
Mutating Admission	修改请求对象	默认值注入、sidecar 注入	先变更再校验
Validating Admission	校验请求对象	Webhook、ValidatingAdmissionPolicy	策略不通过则拒绝写入
Persistence	写入 etcd	storage layer	写入后其他组件通过 watch 感知

RBAC 与 ServiceAccount

对象	作用	注意点
Role	namespace 级权限集合	只能授予本 namespace 内资源权限
ClusterRole	集群级权限集合	可用于集群资源，也可被 RoleBinding 绑定到 namespace
RoleBinding	把 Role/ClusterRole 授给主体	作用域是 namespace
ClusterRoleBinding	集群范围授权	权限很大，生产要谨慎
ServiceAccount	Pod 内访问 API Server 的身份	配合最小权限原则

回答 RBAC 时要强调“主体 subject、动作 verb、资源 resource、作用域 namespace/cluster”四个维度。

Admission、Webhook 与策略治理

机制	适合做什么	风险/注意点
MutatingAdmissionWebhook	注入 sidecar、默认资源、镜像仓库前缀	要避免循环变更和高延迟
ValidatingAdmissionWebhook	拒绝不合规镜像、特权容器、非法标签	Webhook 故障可能影响 API 写入
ValidatingAdmissionPolicy	用 CEL 写内置校验策略	适合轻量规则，减少外部 webhook 依赖
Pod Security	限制特权、宿主机 namespace、危险能力	按 namespace enforce/audit/warn 逐步推进
OPA/Gatekeeper/Kyverno	更完整的策略即代码	需要治理策略复杂度和误伤

多租户资源治理

机制	解决的问题	AI Infra 场景
Namespace	基础隔离边界	按团队、项目、环境隔离
ResourceQuota	限制 namespace 资源总量	限制 CPU、内存、Pod 数、PVC、GPU 扩展资源
LimitRange	设置单 Pod/容器默认值和上下限	防止用户不写 requests 或申请过大
PriorityClass	定义任务优先级	线上推理优先于离线训练，关键任务可抢占
Queue	批任务排队和准入	Kueue/Volcano 按队列管理训练任务
Quota borrowing	空闲配额可临时借用	提升 GPU 利用率
Reclaim	高优任务需要资源时回收借用资源	保证关键队列 SLA

ResourceQuota 与 LimitRange 的区别

这两个对象经常一起出现，但治理层级不同：ResourceQuota 管 namespace 总量，LimitRange 管单个 Pod / Container 的范围和默认值。

维度	ResourceQuota	LimitRange
作用范围	namespace 总量	单个 Pod / Container / PVC
解决问题	防止一个租户占光 namespace 资源	防止单个对象不写 request 或申请过大
典型限制	CPU/Memory 总 requests、Pod 数、PVC 数、GPU 扩展资源总量	每个容器 request/limit 的最小、最大、默认值
失败表现	创建对象时被 admission 拒绝，提示 exceeded quota	对象字段不满足范围或被自动填默认值

面试口径：Quota 控总量，LimitRange 控单体；多租户集群通常两者都要配。

ResourceQuota 基础机制

ResourceQuota 是 namespace 级资源总量约束。它发生在 API Server 的 admission 阶段：当新建或更新对象会导致 namespace 超过配额时，请求会被直接拒绝。

维度	说明	例子
作用范围	单个 namespace	team-a namespace 最多 10 张 GPU
统计对象	对象数量、requests、limits、PVC、Service 等	`pods`、`requests.cpu`、`limits.memory`
统计时机	API 写入前的 admission	超额时对象不会被创建
统计语义	看声明值，不看实时使用量	Pod 实际只用 1 CPU，也按 request 计入 quota
扩展资源	支持 GPU/NPU 等 extended resource	`requests.nvidia.com/gpu: "10"`

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    pods: "100"
    requests.cpu: "200"
    requests.memory: 800Gi
    limits.cpu: "400"
    limits.memory: 1200Gi
    requests.nvidia.com/gpu: "10"
    persistentvolumeclaims: "20"

关键边界：ResourceQuota 是“拒绝超额创建”的 admission 机制，不是“超过后排队等待”的调度机制。

ResourceQuota 常见坑

问题	原因	处理方式
用户不写 requests，Pod 创建被拒	namespace 有 quota 时，缺失 request 可能无法统计	配合 LimitRange 设置默认 request/limit
超过 GPU 配额后任务直接失败	ResourceQuota 是 admission 拒绝，不是队列系统	需要 Kueue / Volcano / AIJob Queue Controller 做排队
Pod 实际使用很低但 quota 满了	quota 统计 requests，不看实时利用率	优化 request，或引入借用/回收机制
只限制 CPU/Memory，GPU 被抢光	没有把 extended resource 纳入 quota	添加 `requests.nvidia.com/gpu` 等扩展资源配额
对象数量过多导致控制面压力	只限制资源量，没限制 object count	限制 pods、services、secrets、configmaps、PVC 数量

安全题常见误区

不要把 RBAC 和 NetworkPolicy 混为一谈：RBAC 管 API 权限，NetworkPolicy 管网络流量。
不要认为 namespace 是强安全隔离：它是逻辑隔离，还需要 RBAC、Quota、NetworkPolicy、Pod Security 配合。
不要让 Webhook 无超时、无降级策略：它可能成为 API Server 写路径上的稳定性风险。
不要给默认 ServiceAccount 过大权限：Pod 被攻陷后会扩大影响面。
不要只限制 CPU/内存而忘记扩展资源：GPU 集群要把 nvidia.com/gpu、NPU 等纳入 Quota。

Secret 管理：默认不是加密，是 base64

面试常考的"陷阱题"：Kubernetes 的 Secret 不是加密的，它在 etcd 里默认只是 base64 编码。生产环境要叠加 etcd 加密、外部 Secret 系统、最小化挂载和审计。

层次	解决的问题	典型实现	面试关注点
默认 Secret	把敏感数据从 Pod 配置中分离	base64 + RBAC 控制访问	不是加密，只是编码；任何能读 Secret 的人都能解码
etcd 加密 at rest	把 Secret 在 etcd 里加密存储	`EncryptionConfiguration` + KMS provider	需要在 API Server 启用 `--encryption-provider-config`
External Secrets Operator	把外部 KV 系统映射为 K8s Secret	对接 Vault / AWS SM / GCP SM	Secret 来源可控，可以做 rotate / audit
CSI Secret Store	不创建 K8s Secret，直接以卷形式挂载	Vault CSI、AWS / Azure / GCP provider	避免 Secret 在 etcd 落盘，也支持自动 rotate
SPIFFE / SPIRE	给工作负载发短期身份证书（mTLS）	SPIRE Server + Agent + Workload API	用 SVID 替代长期 token，减少凭据泄漏
Workload Identity	把 ServiceAccount 映射为云 IAM 身份	GKE Workload Identity / IRSA	Pod 不需要在 Secret 里存云密钥

面试口径：Secret 默认不是加密的，生产至少要做"etcd at-rest 加密 + RBAC 最小权限"；进一步通过 External Secrets / CSI Secret Store / Workload Identity 把凭据生命周期交给外部系统。

etcd 加密 at rest 的工作方式

API Server 通过 EncryptionConfiguration 配置加密 provider，按资源类型决定哪些对象在写 etcd 前被加密。顺序很重要：第一个 provider 用于加密，所有 provider 用于解密，所以滚动启用加密时要逐步切换。

Provider	说明	适用场景
`identity`	不加密，明文写 etcd	默认值，仅用于初始或回退
`aescbc` / `aesgcm`	用本地密钥做 AES 加密	简单加密，密钥保存在 API Server 节点
`secretbox`	NaCl secretbox	类似 aescbc，依赖外部库
`kms`	用外部 KMS 包装 DEK	生产推荐，密钥不在节点本地

面试常追问

"已经写入 etcd 的旧 Secret 会自动被加密吗？"不会。需要 kubectl get secrets -A -o yaml | kubectl replace -f - 之类的操作触发重写，或写个 controller 周期性 touch。轮换 KMS 密钥同样要走这个流程。

镜像安全：签名、扫描、SBOM、admission

容器镜像是供应链攻击的高危环节。完整的镜像安全闭环不是单点，而是从构建到准入的链路。

阶段	做什么	典型工具	面试要点
构建	固定 base 镜像、最小化层、只装必要依赖	distroless / chainguard / 多阶段构建	不要在镜像里内嵌长期凭据
SBOM 生成	列出镜像内所有组件和版本	syft、Trivy SBOM	有 SBOM 才能在 CVE 出现时快速反查影响面
漏洞扫描	对镜像做 CVE 扫描	Trivy、Grype、Clair	CI 阶段拒绝高危 CVE，不要等上线再扫
镜像签名	给镜像打可验签的签名	Cosign / Sigstore	签名 + 透明日志（Rekor），防止中间篡改
准入验证	集群只接受可信镜像	Kyverno / Gatekeeper / Connaisseur 验签策略	在 Validating Admission 阶段拒绝未签名/未扫描镜像
运行时	对运行中容器做行为检测	Falco、Tetragon	补救供应链漏过的部分

Audit Log：谁在什么时候做了什么

API Server 审计日志是合规和事故复盘的核心证据。它通过 --audit-policy-file 配置，定义"哪些请求记录到什么级别"。

级别	记录什么	典型用途
None	不记录	明确忽略噪声，比如健康检查
Metadata	请求元数据（who / what / when）	大部分请求的默认级别，体积小
Request	元数据 + 请求体	关注 spec 变更（如 RBAC、Pod 创建）
RequestResponse	元数据 + 请求体 + 响应体	合规审计、敏感资源（Secret、token）

排障问题	用 audit log 怎么查
谁删了某个 Pod	过滤 `verb=delete, resource=pods, name=xxx`
谁绑定了 cluster-admin	过滤 `resource=clusterrolebindings, verb=create/update`
Token 是否被外部使用	过滤 `user.username=system:serviceaccount:...` + 来源 IP
Secret 是否被异常读取	对 Secret 启用 RequestResponse 级别记录 GET

面试口径：Audit Policy 决定"记什么"，sink（File / Webhook）决定"送到哪"，体积大要按级别和 namespace 收敛，敏感资源单独提级。

API Priority and Fairness（APF）：API Server 限流的现代方案

老版本 K8s 用 --max-requests-inflight 全局限流，单一控制器抖动就能把整个 API Server 打满。1.20+ 默认启用 APF：把请求按 FlowSchema 分流到不同 PriorityLevelConfiguration，再做公平排队和限流。

对象	作用	例子
FlowSchema	按 user / SA / verb / resource 把请求分到某个 PL	kube-system 控制器 → 高优先级，普通用户 → 低优先级
PriorityLevelConfiguration	定义优先级的并发份额、排队策略	`system`、`workload-high`、`workload-low` 等
flow distinguisher	同一 PL 内做公平区分	按 user 区分，避免单租户挤占
排队 vs 拒绝	满了后排队还是直接 429	关键控制器 PL 通常排队，普通客户端可拒绝

面试口径

大集群里被 429 不一定是 client 写错代码，更常见是某个 controller 把对应 FlowSchema 的 PL 占满。排查路径：看 API Server apiserver_flowcontrol_* 指标，定位是哪个 PriorityLevel 在排队/拒绝，再反查 FlowSchema 找出始作俑者。

ValidatingAdmissionPolicy（VAP）：用 CEL 替代 webhook 的轻量策略

在没有 VAP 之前，做"拒绝特权容器""强制带 owner label"这类校验都得写 ValidatingAdmissionWebhook，运维成本高、还可能成为写路径稳定性风险。VAP 是 1.30 GA 的内置机制，用 CEL 在 API Server 内嵌执行，不需要部署外部 webhook。

对象	作用
`ValidatingAdmissionPolicy`	定义策略，用 CEL 表达式判断 `object` / `oldObject` / `params` 是否合法
`ValidatingAdmissionPolicyBinding`	把 policy 绑定到 namespace / 资源 / 参数对象
params	引用一个配置 CR，让同一策略复用不同参数
actions	Deny / Warn / Audit，可以分级别处理

对比维度	Webhook	VAP（内置 CEL）
部署	需要起 Pod、配置 TLS、维护 SLO	API Server 内置，零部署
性能	多一次远程调用，延迟敏感	本地执行，毫秒级
稳定性风险	Webhook 挂了可能影响 API 写入	无外部依赖
表达能力	任意代码	CEL，足够覆盖大多数策略
适合场景	跨集群对接、复杂逻辑、需要外部数据	静态规则、最小权限基线

面试口径：写得清楚的静态准入策略优先用 VAP（CEL），需要动态外部数据或跨系统调用才上 Webhook；这是替代 OPA/Gatekeeper 中相当一部分简单策略的方向。

安全、准入与多租户高频问答

本模块的问答按“概念 → 作用 → 链路/排查 → 面试口径”组织，避免只背一段结论。

Q: RBAC、Admission、Pod Security 分别解决什么问题？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. RBAC 解决权限问题

RBAC 判断某个 subject 是否能对某类 resource 执行某个 verb，例如某用户能否在某 namespace create pods。

2. Admission 解决准入策略问题

Admission 发生在认证鉴权之后、写入 etcd 之前，可以变更对象或校验对象，例如注入 sidecar、拒绝非法镜像。

3. Pod Security 解决 Pod 安全基线问题

Pod Security 限制特权容器、hostNetwork、hostPID、危险 capabilities、root 运行等高风险配置。

4. 三者关系

RBAC 管“谁能做”，Admission 管“请求对象是否合规”，Pod Security 是针对 Pod 安全字段的一类准入策略。

面试口径：RBAC 是权限，Admission 是写入前策略，Pod Security 是 Pod 运行安全基线，三者处在 API Server 请求链路不同阶段。

Q: 一个用户说自己没有权限创建 Pod，怎么排查？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 确认身份和范围

先确认用户、组、ServiceAccount 和 namespace，权限问题必须带着作用域看。

2. 验证 RBAC

用 kubectl auth can-i create pods -n xxx --as user 验证，再检查 Role/ClusterRole 和 Binding 是否正确。

3. 区分非 RBAC 拒绝

如果 RBAC 允许但仍失败，继续看 Admission Webhook、ResourceQuota、LimitRange、Pod Security、镜像策略等是否拒绝。

4. 生产建议

按最小权限原则授权，不要直接给 cluster-admin；默认 ServiceAccount 也不要绑定过大权限。

面试口径：权限排查先确认身份和 namespace，再用 can-i 验证 RBAC，最后排查 Admission、Quota 和 Pod Security。

Q: 多租户 GPU 集群如何做公平性和利用率平衡？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 基础隔离

用 namespace、RBAC、ResourceQuota、LimitRange 隔离团队和资源，GPU 扩展资源也要纳入 quota。

2. 队列治理

用 Kueue、Volcano 或自研队列表达团队配额、优先级、借用和回收策略。

3. 公平性

用 PriorityClass、DRF、quota borrowing/reclaim 等机制，让关键任务有保障，普通任务不被长期饿死。

4. 利用率

空闲 GPU 可以借用给低优任务；高优任务到来时通过抢占、重排或 checkpoint 恢复释放资源。

面试口径：多租户 GPU 集群要同时做权限隔离、配额公平、空闲借用和高优任务回收，不能只靠 namespace。

Q: ResourceQuota 为什么不能实现“超过 10 张 GPU 后排队”？

因为 ResourceQuota 是 API Server admission 阶段的硬拒绝机制。对象一旦会导致 namespace 超过 quota，API Server 直接拒绝创建，不会把这个任务保存成“等待中”的对象，也不会让 scheduler 以后自动再试。

正确做法

如果业务语义是“允许继续提交，但超过 10 张 GPU 后排队”，应该引入任务级队列，例如 Kueue、Volcano，或者自研 AIJob + AIQueue + Queue Controller。排队发生在 Pod 创建前，准入后再创建 Pod。

面试口径：ResourceQuota 管硬上限，Queue 管等待；不要用 quota 代替队列。

Q: 为什么 ResourceQuota 通常要配合 LimitRange？

ResourceQuota 统计 namespace 总量，很多统计项依赖 Pod 的 requests / limits。如果用户不写 requests，系统可能无法准确计入 quota，或者对象被拒绝。LimitRange 可以为容器设置默认 request/limit，也可以限制单个容器的最小/最大资源，保证 quota 有可统计的输入。

面试口径：LimitRange 给单体对象设默认值和上下限，ResourceQuota 再管 namespace 总量，两者配合才完整。

Q: K8s Secret 是不是加密的？生产怎么管 Secret？

回答思路：先纠正"Secret 默认加密"这个误解，再讲分层方案。

1. 默认行为

Secret 在 etcd 里默认是 base64 编码，不是加密。任何能 read Secret 的人都能解码出明文。

2. 第一层：etcd 加密 at rest

API Server 配 EncryptionConfiguration，建议用 KMS provider（密钥不在节点本地）；旧 Secret 不会自动加密，需要重写一遍。

3. 第二层：外部 Secret 系统

用 External Secrets Operator 或 CSI Secret Store，把真正的 Secret 留在 Vault / AWS SM 等系统，K8s 只持有引用或挂载，并支持自动 rotate。

4. 第三层：身份替代

用 Workload Identity（IRSA / GKE WI）让 Pod 直接用云 IAM 身份，避免在 Secret 里存 access key；用 SPIFFE/SPIRE 给工作负载发短期 mTLS 证书。

面试口径：Secret 默认只是 base64，生产至少做 etcd 加密 + RBAC 最小权限，进阶用外部 Secret 系统和 Workload Identity 把凭据生命周期外置。

Q: 大集群里大家被 429 限流，怎么定位？

回答思路：不要直接调大 inflight，要先理解 APF 把请求分到了哪个 PriorityLevel。

1. 看是不是 APF 在拒绝

1.20+ 默认启用 APF，429 通常带 Retry-After 头，对应某个 PriorityLevel 满了。看 API Server apiserver_flowcontrol_request_concurrency_in_use、apiserver_flowcontrol_rejected_requests_total 指标。

2. 定位 FlowSchema

用指标里的 flow_schema、priority_level 标签反查：哪个 FlowSchema 命中、哪个 PL 在排队/拒绝。

3. 找始作俑者

同一 PL 内通过 flow distinguisher（如 user）看是不是某个 controller / SA 在打高 QPS，常见是写循环、watch 重连风暴或 finalizer 死循环。

4. 缓解方式

修客户端（指数退避、合并 update）；调整 FlowSchema 把关键 controller 提到独立 PL；必要时为该 PL 增加 assured concurrency shares。

面试口径：429 不是单纯调大并发就能解决，要按 APF 的 FlowSchema → PriorityLevel → flow distinguisher 链路定位"是谁把哪个优先级队列打满"。

Q: ValidatingAdmissionPolicy 和 OPA/Gatekeeper、Kyverno 怎么选？

回答思路：从部署成本、表达力、稳定性影响、动态数据需求四个维度比。

1. 静态最小权限基线

"禁止特权容器""强制带 owner label""限制镜像仓库前缀"这类规则，用 VAP 最合适，零部署，毫秒级，写路径无远程调用。

2. 复杂或动态策略

需要查外部数据（IAM、CMDB）、跨集群同步、做 mutation 或全量审计的，仍要靠 OPA/Gatekeeper 或 Kyverno，因为它们能跑任意逻辑。

3. 稳定性

Webhook 挂了可能阻塞 API Server 写路径，必须配超时和 failurePolicy=Ignore；VAP 没这个问题。

4. 治理

真实集群往往是混合：80% 静态规则用 VAP，20% 复杂策略用 Kyverno/Gatekeeper；都要做策略灰度（先 Audit/Warn 再 Deny）。

面试口径：能用 CEL 表达的策略优先 VAP，需要外部数据或复杂逻辑才上 Kyverno/Gatekeeper；新策略上线一律先 Audit/Warn，再切 Deny。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

内容模块

故障排查与稳定性

进阶★☆☆⏱ 18 min

一句话结论

K8S 排障要从状态、事件、日志、资源、网络、节点和控制面逐层收敛。

复习定位

维度	内容
所属模块	Kubernetes 核心
章节类型	排障诊断类
解决问题	围绕控制面、调度资源模型、Workload Controller、网络存储、安全多租户、排障和 AI Infra GPU/DRA 建立平台面试答案。
面试抓手	先 kubectl describe/events/logs，再看 kubelet/CNI/CSI/control plane。

故障排查总方法：从症状反推链路

Kubernetes 排障不要一上来背命令，而要按链路拆：API 对象是否存在 → 调度是否成功 → kubelet 是否执行 → 网络/存储是否就绪 → 应用是否健康 → 控制器是否持续修正。

先看状态：kubectl get、kubectl describe、Events。
再看控制器：Deployment/ReplicaSet/Job/StatefulSet 的 conditions。
再看节点：Node condition、kubelet、container runtime、CNI、CSI。
再看应用：容器日志、探针、启动参数、依赖服务。
最后看系统性问题：资源压力、API Server、etcd、scheduler、网络插件、存储后端。

高频故障速查

症状	优先看什么	常见原因	定位方向
Pod Pending	Pod Events、scheduler 日志	资源不足、污点、亲和性、PVC、配额、DRA claim	调度与准入链路
ContainerCreating	Events、kubelet 日志	镜像、CNI、CSI mount、sandbox 创建失败	节点执行链路
CrashLoopBackOff	容器日志、退出码、探针	程序启动失败、配置错误、依赖不可用、liveness 过激	应用与探针
ImagePullBackOff	Events、镜像仓库、Secret	镜像不存在、权限错误、网络不可达	镜像拉取链路
Service 不通	Service、EndpointSlice、readiness、DNS	selector 错、无 endpoints、网络策略、kube-proxy/CNI	网络链路
Node NotReady	Node conditions、kubelet、runtime	节点宕机、磁盘/内存压力、网络异常、证书问题	节点健康
PVC Pending	PVC Events、StorageClass、CSI	StorageClass 不存在、容量不足、拓扑不匹配、provisioner 异常	存储链路

Pod Pending 深入排查

看 kubectl describe pod 中 FailedScheduling 的具体原因。
如果是资源不足，对比 Pod requests 和 Node allocatable，注意 DaemonSet、系统预留和碎片。
如果是污点，检查 tolerations；如果是亲和性，检查 nodeSelector、nodeAffinity、podAffinity。
如果是 PVC，检查 PVC 是否 Bound，StorageClass 的 volumeBindingMode 和存储拓扑。
如果是配额，检查 ResourceQuota、LimitRange、队列配额。
如果是 GPU，检查扩展资源、Device Plugin、DRA ResourceClaim/ResourceSlice。
必要时查看 scheduler 日志和调度器 profile/plugin 配置。

CrashLoopBackOff 与 ImagePullBackOff

问题	关键观察	处理思路
CrashLoopBackOff	`kubectl logs --previous`、退出码、启动耗时	修配置、依赖、启动命令；区分应用崩溃和探针杀死
OOMKilled	last state、内存 limit、应用内存曲线	调大 limit、修内存泄漏、优化 batch size
Probe failed	liveness/readiness/startup 配置	慢启动用 startupProbe，readiness 不应导致重启
ImagePullBackOff	Events 中的 registry 错误	检查镜像名、tag、Secret、仓库网络、证书
ErrImagePull	首次拉取失败	修复后 kubelet 会重试，或删除 Pod 触发重建

Pod Phase、重启策略与镜像策略速查

对象/字段	常见值	面试抓手
Pod Phase	Pending / Running / Succeeded / Failed / Unknown	Phase 是 Pod 总体状态，不等同于单个容器状态
Container State	Waiting / Running / Terminated	CrashLoopBackOff、ImagePullBackOff 属于 Waiting reason
`restartPolicy`	Always / OnFailure / Never	Deployment 通常 Always；Job 常用 OnFailure / Never
`imagePullPolicy`	Always / IfNotPresent / Never	`:latest` 默认 Always；生产建议固定 tag 或 digest

面试口径：Pod Phase 看整体，Container State 看容器细节；重启策略控制退出后是否重启，镜像策略控制启动前是否拉镜像。

Probe 三件套

Probe	作用	失败后行为
`readinessProbe`	判断能否接流量	从 Service endpoints 移除，不重启容器
`livenessProbe`	判断是否需要自愈重启	kubelet 重启容器
`startupProbe`	给慢启动应用更长启动窗口	成功前延迟 liveness/readiness 生效

面试口径：readiness 管流量，liveness 管重启，startup 保护慢启动。

稳定性治理：HPA / VPA / PDB / drain

机制	解决什么问题	注意点
HPA	按指标水平扩缩副本	依赖 metrics，扩缩容要结合 readiness 和冷启动
VPA	推荐或调整单 Pod 资源	自动模式可能重建 Pod，和 HPA 同时使用要谨慎
PDB	限制自愿驱逐时不可用副本数	不能阻止节点故障，只影响 drain/升级等自愿驱逐
drain	节点维护前驱逐 Pod	受 PDB、DaemonSet、emptyDir、本地盘影响
TopologySpread	让副本跨节点/可用区分散	提高容灾，避免热点

大规模集群稳定性关注点

层面	风险	治理手段
API Server	高 QPS、watch 风暴、大对象膨胀	限流、分页、合理 watch、减少频繁 status 更新
etcd	存储膨胀、慢查询、碎片、磁盘延迟	监控 fsync、compact、defrag、备份恢复演练
scheduler	调度队列堆积、插件耗时、资源碎片	profile 优化、批调度准入、减少复杂亲和性
节点	kubelet 压力、镜像拉取风暴、磁盘压力	镜像预热、系统预留、节点池隔离、驱逐阈值
网络	连接数、DNS QPS、Service 规模、策略复杂	CoreDNS 扩容、NodeLocal DNSCache、eBPF 可观测
AI 训练	Gang 任务占用大量资源、失败重试风暴	队列准入、配额、checkpoint、失败退避、作业优先级

故障排查与稳定性高频问答

本模块的问答按“概念 → 作用 → 链路/排查 → 面试口径”组织，避免只背一段结论。

Q: Pod Pending 你会怎么排查？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 先定位阶段

Pending 可能卡在调度、PVC、配额、准入或镜像前准备阶段，先看 Pod Events 确认具体原因。

2. 调度失败

如果是 FailedScheduling，检查 requests、Node allocatable、污点容忍、亲和性、拓扑约束、优先级抢占。

3. 依赖未满足

如果事件指向 PVC、ResourceClaim、Quota、LimitRange 或队列准入，就去对应模块看存储、DRA、配额和批调度。

4. 节点执行前问题

如果已经绑定但仍 Pending/ContainerCreating，检查 kubelet、CNI、CSI、container runtime、镜像拉取和 sandbox 创建。

面试口径：Pending 不是单一问题，要先看 Events 判断卡在调度、存储、配额、设备还是节点执行链路。

Q: CrashLoopBackOff 怎么排查？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 理解概念

CrashLoopBackOff 表示容器反复启动失败，kubelet 正在按退避策略重启它；它是结果，不是根因。

2. 先看日志和退出码

看 kubectl logs 和 kubectl logs --previous，再看 lastState、exitCode、reason、启动命令和参数。

3. 区分常见根因

配置错误、依赖不可达、启动命令错误、权限问题、镜像入口错误、OOMKilled、应用主动退出都可能导致循环重启。

4. 检查探针

livenessProbe 过激会把慢启动应用杀死；慢启动应使用 startupProbe，readiness 失败不应导致重启。

面试口径：CrashLoopBackOff 按“日志/退出码 → 配置和依赖 → OOM → 探针”排查，先找容器为什么退出。

Q: Node NotReady 怎么排查？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 看 Node conditions

先看 Ready、MemoryPressure、DiskPressure、PIDPressure、NetworkUnavailable，判断是资源压力还是节点不可达。

2. 看节点侧组件

登录节点检查 kubelet、container runtime、CNI、磁盘、内存、网络、证书和系统日志。

3. 看控制面连接

确认 API Server 能否收到节点心跳，网络、防火墙、证书过期、kubelet bootstrap 都可能影响上报。

4. 看影响面

评估该节点上的 Pod 是否 Unknown/Terminating，是否需要 cordon、drain、重建或等待节点恢复。

面试口径：Node NotReady 先看 conditions，再查 kubelet/runtime/CNI/资源压力和控制面连通性，最后评估 Pod 迁移影响。

Q: 大规模集群为什么要关注 watch 和对象大小？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. watch 的作用

Kubernetes 组件大量依赖 List/Watch 感知对象变化，watch 是控制器、scheduler、kubelet 协作的基础。

2. 对象过大的风险

Node status、Pod status、ResourceSlice 等对象过大会增加 API Server 序列化、网络传输、缓存和 etcd 存储压力。

3. 更新过频的风险

频繁 status 更新会放大 watch 广播和 etcd 写入压力，导致控制面 QPS、延迟和内存上升。

4. 治理方式

控制对象大小、减少无意义 status 更新、合理分片、使用分页和限流，DRA 用 ResourceSlice 也是为了避免 Node 对象无限膨胀。

面试口径：大集群稳定性要控制 watch 数量、对象大小和更新频率，否则 API Server 与 etcd 会成为瓶颈。

etcd 故障排查：raft、defrag、备份

etcd 是 K8s 的"单点真相"，控制面所有问题最终都会落到 etcd 上。面试常考 etcd 抖动后控制面有什么症状，怎么定位。

典型症状	底层原因	处理
API Server 5xx、kubectl 卡顿	etcd leader 选举失败 / 慢盘	看 `etcd_server_has_leader`、`etcd_disk_wal_fsync_duration_seconds`，换 SSD 或独立磁盘
etcd "took too long" 警告	大事务、慢盘、内存压力	分析慢请求的 key 前缀，限制大对象（CRD/Lease 风暴）
etcd 数据库膨胀	历史 revision 太多没有 compact	开启 auto compaction，定期 `etcdctl defrag`
NOSPACE alarm	db size 超 quota	调大 `--quota-backend-bytes`、defrag、删冗余对象
raft 心跳超时	跨可用区 / 跨地域延迟过高	etcd 必须低延迟，建议同 AZ 同机房；不要跨 region 部署 etcd
数据损坏	磁盘故障 / 异常关机	需要从 snapshot 恢复，所以备份和恢复演练必须常态化

关键指标	含义	报警阈值参考
`etcd_server_has_leader`	是否有 leader	持续 0 立刻告警
`etcd_server_leader_changes_seen_total`	leader 变更次数	短时多次切主，通常是慢盘或网络
`etcd_disk_wal_fsync_duration_seconds` p99	WAL 落盘耗时	>25ms 危险，需要立刻查盘
`etcd_disk_backend_commit_duration_seconds` p99	事务提交耗时	>25ms 危险
`etcd_mvcc_db_total_size_in_bytes`	数据库大小	接近 quota 时安排 defrag

面试口径：etcd 出问题先看 leader、WAL fsync、backend commit 三个指标；优化方向是独立 SSD、控制对象数量和 watch 风暴、定期 compact + defrag、跨 AZ 三节点而不是跨 region。

控制面 HA：API Server / Scheduler / Controller Manager

控制面的高可用模式不一样：API Server 是无状态，多副本同时工作，前面挂 LB；Scheduler 和 Controller Manager 是有状态，多副本通过 leader election 选主，一主多备。

组件	HA 模式	关键依赖	面试要点
API Server	多副本 active-active	前置 LB（HAProxy / 云 LB）+ etcd	客户端用 LB VIP 而不是直连某个节点
etcd	奇数节点 raft 集群（3 / 5）	低延迟磁盘和网络	quorum 是 N/2+1，3 节点最多挂 1，5 节点最多挂 2
kube-scheduler	leader election，主备	API Server 上的 Lease 对象	主副本挂掉后秒级切主，调度短暂停顿
kube-controller-manager	leader election，主备	同上	同上，注意 `--leader-elect-renew-deadline`
cloud-controller-manager	leader election	云 API	主备切换不要太频繁，否则云资源回收抖动
kubelet / kube-proxy	每节点一个，独立	API Server 可达	没有 HA 概念，节点级单点

面试口径

控制面 HA 不是简单"复制 3 份"：API Server 是无状态多活，etcd 是 raft quorum，scheduler / CM 是 leader election 主备。整体 SLO 取决于木桶最短板，绝大多数事故的根因都在 etcd（慢盘、跨 AZ 延迟、对象膨胀）。

API Server 过载：怎么定位与缓解

"控制面慢"是大集群最常见的"症状"，背后可能是 API Server / etcd / 客户端任意一环。

分层	常见原因	定位指标
客户端	controller 写循环、watch 重连风暴、finalizer 死循环	`apiserver_request_total` 按 user / verb / resource 拆
API Server	反序列化大对象、admission webhook 慢、APF 排队	`apiserver_request_duration_seconds`、`apiserver_admission_webhook_admission_duration_seconds`
etcd	慢盘、leader 抖动、db 太大	`etcd_disk_*` 系列指标
watch 缓存	cacher 满 → resourceVersion too old / watch error	`apiserver_watch_cache_*`

缓解动作	说明
开启/调优 APF	把关键 controller 提到独立 PriorityLevel，普通客户端限流
缩减对象数量和大小	合并 status 更新、清理无主 Pod / Event、Lease 用 v1 版
合理分页 List	客户端禁止 List 全量大资源（Pod / Event），改为 paginated 或 informer
升级 etcd 磁盘	独立 NVMe，避免和 kubelet / 容器盘共用
限制 webhook	缩短超时、failurePolicy=Ignore、避免阻塞核心资源

集群网络故障：DNS、conntrack、MTU

"Pod 偶发超时"通常不是业务代码而是网络层的问题。这几个高频根因建议背下来。

故障	典型症状	定位	修复
CoreDNS 抖动	偶发解析失败、5s 延迟	`kubectl logs coredns`、客户端 `ndots`、retry	启用 NodeLocal DNSCache，调小 ndots 或写 FQDN
conntrack 表打满	连接 reset、新连接建立失败	看节点 `nf_conntrack_count` / `max`	调大 `nf_conntrack_max`，必要时切 eBPF 模式绕过
MTU 不一致	大包丢失、TLS 握手失败但 ping 通	抓包看是否在大包处卡住	统一 overlay MTU（如 1450）、检查 PMTUD 是否被 ICMP 黑洞
kube-proxy 同步慢	新建 Service 几十秒不通	看 kube-proxy `sync_proxy_rules_duration_seconds`	切到 IPVS / eBPF
NetworkPolicy 误杀	原本通的连接突然不通	对比 NP 变更和现象时间线	放行 DNS、明确 Egress 列表
跨 AZ / region 抖动	P99 高、AllReduce 慢	看物理网络指标 + 拓扑感知调度	训练任务 same leaf 调度，避免跨 spine

故障排查 SOP：从现象到根因的标准动作

面试常被问"线上 Pod 怎么排查"，面试官想看的不是技巧而是系统化方法。下面这个 SOP 适用于绝大多数 K8s 故障。

步骤	看什么	命令 / 工具
1. 现象	Pod 状态、Service 通否、用户报错	`kubectl get pods -o wide`、`kubectl describe`
2. Events	调度、拉镜像、探针、OOM 都会留痕	`kubectl get events --sort-by=.lastTimestamp`
3. 容器日志	当前 + 上一容器的日志	`kubectl logs -f`、`kubectl logs --previous`
4. 节点侧	kubelet / runtime / 内核日志	登录节点 `journalctl -u kubelet`、`dmesg -T`
5. 控制面	API Server / scheduler / CM / etcd	看指标和日志，确认控制面是否同样异常
6. 网络面	DNS / Service / NetworkPolicy / CNI	从故障 Pod 内 `nslookup` / `curl`，再到节点抓包
7. 时间线对照	变更（发布、配置、节点回收）	结合 audit log 和 CMDB 找时间相关性
8. 假设验证	缩小到一个假设，主动复现	测试 namespace、灰度修复、最小复现脚本

面试口径：故障排查不是猜，要按"现象 → events → 日志 → 节点 → 控制面 → 网络 → 变更时间线"的顺序逐层下钻；先收敛假设，再做最小复现验证。

Q: etcd 抖动会让 K8s 出现什么症状？怎么定位？

回答思路：从用户能看到的症状反推到 etcd 指标，再讲常见根因。

1. 用户侧症状

kubectl 卡顿、API Server 5xx、controller reconcile 间断、scheduler 调度停顿、Pod status 上报滞后。

2. 控制面指标

看 API Server 写延迟（apiserver_request_duration_seconds）和 etcd 的 has_leader、leader_changes_seen_total、wal_fsync、backend_commit。

3. 常见根因

慢盘（fsync 飙到几十毫秒）、跨 AZ 延迟、db 太大没 compact、Lease/Event 风暴、大对象（如巨型 ConfigMap）频繁更新。

4. 缓解

独立 NVMe、定期 compact + defrag、限制单对象大小、修客户端 watch 风暴；恶劣情况下从 snapshot 恢复。

面试口径：etcd 抖动表现为控制面整体慢，定位看 leader / WAL fsync / backend commit，根因多在磁盘和对象膨胀。

Q: 控制面 HA 怎么设计？为什么不能跨 region 部署 etcd？

回答思路：区分组件无状态 / 有状态，再讲 etcd 对延迟的硬性要求。

1. 无状态组件

API Server 多副本 active-active，前面挂 LB；客户端访问的是 LB VIP，不绑定节点。

2. 有状态组件

scheduler / controller-manager 通过 Lease 做 leader election，主备秒级切换；切换时短暂停顿是可接受的。

3. etcd 是 raft

raft 每次写都需要 quorum，跨 region 的网络延迟（几十毫秒）会让每次写延迟翻倍，整个 K8s 慢到不可用。

4. 推荐部署

etcd 同 region 跨 AZ 三节点（最多挂 1）或五节点（最多挂 2）；跨 region 用多集群联邦或 fleet，而不是单集群跨 region。

面试口径：控制面 HA = API Server 多活 + etcd raft quorum + scheduler/CM leader election；etcd 不能跨 region 是因为 raft 每写都要 quorum，延迟敏感。

Q: Pod 偶发超时但不是 OOM，可能是什么？

回答思路：排除业务后聚焦"网络层 / 内核层 / DNS"。

1. DNS

CoreDNS 抖动 + 客户端没 NodeLocal DNSCache 时，常见 5s 超时（resolv.conf 默认 timeout）；ndots 过大也放大 DNS 次数。

2. conntrack

节点 nf_conntrack_max 不够大，新连接被丢；典型症状是高峰期连接重置、ECONNRESET。

3. MTU

overlay MTU 没和物理网卡对齐，TLS 握手等大包卡住，但小包（ping）正常，迷惑性强。

4. kube-proxy

iptables 模式下 Service 变更扫描慢、conntrack 老化也会偶发；切 IPVS / eBPF 通常能稳定下来。

面试口径：偶发超时优先看 DNS（5s 这个数字几乎就是签名）、conntrack 容量、MTU 一致性，再看 kube-proxy 模式。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

内容模块

AI Infra：GPU / 批调度 / DRA

精通★☆☆⏱ 20 min

一句话结论

AI Infra 里的 K8S 难点在 GPU device plugin、MIG/MPS、拓扑、Gang 调度、Kueue/Volcano 和 DRA。

复习定位

维度	内容
所属模块	Kubernetes 核心
章节类型	系统类
解决问题	围绕控制面、调度资源模型、Workload Controller、网络存储、安全多租户、排障和 AI Infra GPU/DRA 建立平台面试答案。
面试抓手	把 K8S 抽象和 GPU 物理资源语义连接起来。

AI Infra：GPU / 批调度 / DRA 总览

AI Infra 场景下，Kubernetes 的核心问题从“跑一个无状态服务”扩展为：如何接入 GPU/NPU 等异构硬件，如何让分布式训练一组 Pod 同时拿到资源，如何表达显存、拓扑、MIG、NVLink、NUMA 等复杂约束。

方向	解决的问题	代表机制
设备接入	让 kubelet 和 scheduler 看到 GPU/NPU	Device Plugin、Extended Resource、DRA
设备共享	提高 GPU 利用率	MIG、MPS、time-slicing、vGPU
拓扑感知	减少跨 NUMA、跨 PCIe、跨 NVLink 通信损耗	Topology Manager、scheduler plugin、DRA attributes
批调度	训练任务需要一组 Pod 同时运行	Gang Scheduling、Volcano、Kueue
队列治理	多团队 GPU 配额、公平性和抢占	Queue、ClusterQueue、PriorityClass、reclaim/borrowing

GPU Device Plugin：它把 GPU 接进 K8s 的哪一层

Device Plugin 是 kubelet 的节点侧插件机制，用于把 GPU、FPGA、RDMA NIC 等非标准硬件暴露给 Kubernetes。以 NVIDIA GPU 为例，插件通常以 DaemonSet 运行在每个 GPU 节点上，向 kubelet 注册 nvidia.com/gpu 这类扩展资源；kubelet 再把资源数量写入 Node 的 capacity / allocatable，供 scheduler 做整数资源调度。

组件	职责	面试关注点
Device Plugin Pod	发现本机设备，维护设备健康状态，通过 gRPC 向 kubelet 注册资源名	通常是 DaemonSet，只在有对应硬件的节点运行
kubelet Device Manager	接收插件注册，维护设备列表，在 Pod 启动前调用 Allocate	Device Plugin 直接对接 kubelet，不直接对接 scheduler
Node status	展示扩展资源总量和可分配量，例如 `nvidia.com/gpu: 8`	scheduler 主要看到的是资源名和整数数量
kube-scheduler	根据 Pod requests/limits 和 Node allocatable 做过滤与打分	默认不理解 GPU 型号、显存、NVLink、NUMA 等设备内部属性
Container Runtime	根据 kubelet 传入的设备信息把 GPU device node、环境变量、mount 注入容器	常和 NVIDIA Container Toolkit、CDI 等运行时机制配合

Extended Resource 与 Device Plugin

扩展资源是 Kubernetes 资源模型中的“自定义整数资源”，Device Plugin 是最常见的节点侧上报机制。两者关系可以理解为：Device Plugin 负责发现和注册设备，Extended Resource 负责在 Pod spec 和 Node allocatable 中表达可调度数量。

环节	发生什么	关键点
资源注册	Device Plugin 通过 kubelet 注册资源名，例如 `nvidia.com/gpu`	资源名必须带域名前缀，避免和原生资源冲突
库存暴露	kubelet 把数量写入 Node `capacity` / `allocatable`	scheduler 看到的是整数数量，不是每张卡的详细属性
Pod 申请	Pod 在 `resources.limits` 中申请，例如 `nvidia.com/gpu: 1`	GPU 等扩展资源一般要求 requests 与 limits 相等
节点选择	scheduler 根据资源数量过滤节点	默认不理解显存、型号、NVLink、NUMA 等设备属性
设备交付	Pod 到节点后 kubelet 调用 Device Plugin `Allocate`	具体 device node、环境变量、mount 在节点侧注入容器

nvidia.com/a100、nvidia.com/v100 也可以通过 Device Plugin 实现，但本质是把“型号”编码进资源名。当还要表达显存、MIG profile、PCIe/SXM、NUMA、NVLink、健康状态时，资源名和 label 组合会迅速爆炸。

Device Plugin 调度与分配链路

Device Plugin 在节点上发现 GPU，并通过 kubelet 注册资源名，例如 nvidia.com/gpu。
kubelet 更新 Node capacity / allocatable。
用户 Pod 在 resources.limits 中申请 GPU。
scheduler 根据 Node allocatable 和 Pod requests/limits 选择节点。
Pod 绑定到节点后，kubelet 调用 Device Plugin Allocate。
Device Plugin 返回 device id、环境变量、mount、device node 或 CDI 信息。
kubelet 通过 CRI 让容器运行时把设备注入容器。

核心边界：Device Plugin 让 K8s 能看见并交付设备，但默认调度层看到的是资源名和数量，不是完整设备拓扑。

K8s 中 MPS / Time Slicing 的一句话

在 Kubernetes 里使用 MPS 或 Time Slicing，通常不是直接改 kube-scheduler，而是通过 NVIDIA Device Plugin 或 NVIDIA GPU Operator 的配置，把一张物理 GPU 暴露成多个可被 Pod 申请的逻辑 GPU 资源。

scheduler 只看到类似 nvidia.com/gpu.shared: 4 这样的扩展资源数量；底层共享逻辑由 NVIDIA Device Plugin、driver、MPS daemon 或 CUDA/驱动层实现。

K8s 为什么默认不好共享 GPU

Kubernetes 原生资源模型通常把 GPU 当作整数扩展资源。例如 Pod 申请：

resources:
  limits:
    nvidia.com/gpu: 1

这通常表示这个 Pod 要独占 1 张 GPU。默认调度器只根据 Node 上报的 capacity / allocatable 做整数资源扣减，一张 GPU 被分配后，其他 Pod 不能再申请同一张 GPU。

但开发测试、Notebook、小模型推理、小 batch 服务、低优实验等场景经常用不满一张 GPU，所以 NVIDIA Device Plugin 提供 GPU oversubscription 能力，通过 sharing 配置支持 Time Slicing 和 MPS 两种共享方式。

Time Slicing：把一张 GPU 暴露成多个逻辑 slot

Time Slicing 可以理解为多个 Pod 按时间片轮流使用同一张物理 GPU。它不是把 GPU 硬件切开，而是在软件/驱动层做时间片复用。

维度	说明
资源表达	通过 `replicas` 把每张 `nvidia.com/gpu` 暴露成多个逻辑 slot
调度视角	如果 1 张卡配置 `replicas: 4`，K8s 会看到 4 个可申请资源；8 张卡会看到 32 个
隔离能力	没有硬件隔离，显存、cache、带宽和 kernel 执行都会互相影响
适合场景	开发测试、Notebook、小实验、小模型推理、内部工具、低优任务
主要风险	一个 Pod 的重 kernel 或高显存占用会影响其他 Pod，P99 延迟可能明显抖动

Time Slicing 的关键认知：它让 K8s 能调度更多 Pod 到同一张卡上，但不保证每个 Pod 拿到稳定的 1/N 算力或 1/N 显存。

Time Slicing ConfigMap 示例

apiVersion: v1
kind: ConfigMap
metadata:
  name: time-slicing-config
  namespace: gpu-operator
data:
  any: |-
    version: v1
    flags:
      migStrategy: none
    sharing:
      timeSlicing:
        renameByDefault: true
        failRequestsGreaterThanOne: true
        resources:
        - name: nvidia.com/gpu
          replicas: 4

字段	含义	面试解释
`replicas: 4`	每张物理 GPU 暴露成 4 个共享 slot	1 张卡上报 4 个资源，8 张卡上报 32 个资源
`renameByDefault: true`	把共享资源重命名为类似 `nvidia.com/gpu.shared`	让用户明确知道自己申请的是共享 GPU，不是独占 GPU
`failRequestsGreaterThanOne: true`	拒绝单个 Pod 一次申请多个共享 slot	避免用户误以为申请 2 个 slot 就等于拿到 2 张独立 GPU

Pod 如何申请共享 GPU

如果开启 renameByDefault: true，Pod 侧推荐申请重命名后的共享资源：

apiVersion: v1
kind: Pod
metadata:
  name: ts-demo
spec:
  containers:
  - name: app
    image: nvidia/cuda:12.2.0-base-ubuntu22.04
    command: ["nvidia-smi"]
    resources:
      limits:
        nvidia.com/gpu.shared: 1

如果没有开启资源重命名，Pod 仍可能申请 nvidia.com/gpu: 1，但这在语义上容易被误解为独占 GPU。共享资源生产落地时，更推荐使用 nvidia.com/gpu.shared 这类显式资源名。

GPU Operator 如何加载 sharing 配置

如果使用 NVIDIA GPU Operator，常见流程是先创建 ConfigMap，再 patch ClusterPolicy，让 device plugin 读取该配置。

kubectl apply -f time-slicing-config.yaml

kubectl patch clusterpolicies.nvidia.com/cluster-policy \
  -n gpu-operator \
  --type merge \
  -p '{"spec":{"devicePlugin":{"config":{"name":"time-slicing-config","default":"any"}}}}'

管理员创建 sharing ConfigMap。
GPU Operator 或 NVIDIA Device Plugin 加载该配置。
Device Plugin 重新向 kubelet 注册扩展资源数量。
kubelet 更新 Node capacity / allocatable。
scheduler 按新的逻辑资源数量调度 Pod。

注意：不同 GPU Operator / Device Plugin 版本的字段和 patch 命令可能略有差异，但核心模式都是 ConfigMap → Device Plugin → kubelet 上报资源 → Pod 申请扩展资源。

MPS：多 CUDA 进程并发共享 GPU

MPS 是 NVIDIA Multi-Process Service。它让多个 CUDA 进程通过 MPS control daemon 共享同一张 GPU，减少上下文切换开销，并提升小 kernel、多进程推理等场景的并发执行效率。

维度	Time Slicing	MPS
共享方式	多个 workload 按时间片轮流用 GPU	多个 CUDA 进程通过 MPS daemon 并发提交 work
实现直觉	轮流用	一起提交 CUDA work
隔离能力	弱，主要是时间复用	比 Time Slicing 稍强，可做一定计算/显存资源限制
适合场景	开发测试、Notebook、低优任务、小推理	同团队可信任务、小 kernel、多 CUDA 进程推理
不适合场景	强 SLA、强隔离、多租户不可信任务	强硬隔离、大模型训练、显存不可控、不可信用户

面试时要强调：MPS 仍然不是 MIG 那种硬件级隔离。它能改善并发和一定程度资源控制，但故障、显存、cache、带宽和性能干扰仍然可能跨 Pod 传播。

MPS ConfigMap 示例

apiVersion: v1
kind: ConfigMap
metadata:
  name: mps-config
  namespace: gpu-operator
data:
  any: |-
    version: v1
    flags:
      migStrategy: none
    sharing:
      mps:
        renameByDefault: true
        failRequestsGreaterThanOne: true
        resources:
        - name: nvidia.com/gpu
          replicas: 4

这个配置的含义是：每张 GPU 通过 MPS 方式暴露成 4 个共享 slot。Pod 侧仍然通过 resources.limits 申请共享 GPU，例如 nvidia.com/gpu.shared: 1。具体资源名是否重命名取决于 renameByDefault 和当前 device plugin 版本。

生产使用注意事项

问题	说明	工程建议
K8s 不理解性能隔离	scheduler 只看到逻辑资源数量，不知道每个 slot 的真实算力、显存、带宽	不要把 `replicas: 8` 理解为稳定 1/8 GPU
显存互相影响	Time Slicing 下多个 Pod 共享整张卡显存，单个 Pod 高显存占用可能导致其他 Pod OOM	按 workload profiling 设置 replicas，限制不可信任务
延迟抖动	重 kernel、长任务、上下文切换和带宽争用会拉高 P99	强 SLA 在线服务优先用独占 GPU、MIG，或只让同类服务共享
监控归因困难	启用 Time Slicing 后，DCGM-Exporter 对 container 维度 GPU metrics 的归因能力可能受限	补充应用侧指标、队列指标、Pod 级吞吐和延迟观测
过度超卖	`replicas` 配太大容易造成显存爆、上下文切换严重、P99 暴涨	从 2/4 这类保守值灰度，按业务曲线逐步调参

MIG / MPS / Time Slicing / vGPU 对比

机制	隔离粒度	优点	风险	典型场景
MIG	硬件级 GPU 分区	隔离强，profile 清晰	切分形态固定，资源碎片	多租户推理、强隔离生产服务
MPS	进程级共享	提升小任务并发利用率，可做一定资源控制	不是硬隔离，干扰和故障影响复杂	可信团队内多进程推理、小 kernel 任务
Time Slicing	时间片共享	部署简单，兼容性好，适合轻量任务	显存共享，QoS 不稳定，P99 抖动明显	Notebook、开发测试、低优实验、小推理
vGPU	虚拟化切分	适合云化售卖和多租户	依赖厂商方案和授权	云桌面、云 GPU、多租户售卖

批调度：Gang、Kueue、Volcano

分布式训练通常需要 worker、parameter server、launcher 等一组 Pod 同时运行。如果只按单 Pod 调度，可能出现部分 worker 占住 GPU，剩余 worker 长期 Pending，导致资源浪费。Gang Scheduling 要求一组 Pod 要么一起拿到资源，要么一起等待。

机制	定位	面试回答
Gang Scheduling	调度语义	一组 Pod 满足最小可运行数量后再整体放行
Volcano	批调度系统	提供 Queue、PodGroup、Gang、DRF、公平调度等能力
Kueue	K8s 原生批任务准入	更偏资源准入和队列治理，与 Job、RayJob、训练 Operator 集成
Permit 插件	Scheduling Framework 扩展点	可让 Pod 在绑定前等待同组 Pod 凑齐

DRA 是什么

DRA 是 Dynamic Resource Allocation，面向 GPU、DPU、FPGA、NIC 等设备的新一代动态资源分配 API。它的目标不是替代所有 Device Plugin 场景，而是解决传统扩展资源在复杂异构设备上的表达能力不足。

DRA 对象	类比	作用
DeviceClass	StorageClass	管理员定义一类可申请设备及选择规则
ResourceClaim	PVC	用户声明自己需要什么设备
ResourceClaimTemplate	volumeClaimTemplates	为每个 Pod 自动生成相似但独立的 claim
ResourceSlice	设备库存分片	DRA driver 发布设备列表、属性、容量、拓扑和可访问节点
Pod resourceClaims	Pod 引用 PVC	Pod 声明要使用哪些 ResourceClaim

DRA 与传统资源模型的边界

DRA 不是把 resources.requests 简单增强成更复杂的字段，而是引入 resource.k8s.io API，用 ResourceClaim 表达需求、用 ResourceSlice 发布设备库存、用 DeviceClass 抽象设备类别。传统 Extended Resource 适合“资源名 + 整数数量”，DRA 更适合“设备属性 + 容量 + 拓扑 + 共享关系”。

维度	Device Plugin / Extended Resource	DRA
资源表达	资源名 + 整数数量	结构化设备属性、容量、拓扑、选择条件
调度可见性	scheduler 主要看到数量	scheduler 可基于 ResourceSlice 做设备级匹配
适合场景	同质 GPU、简单整卡分配	异构 GPU/NPU/DPU、MIG、拓扑、共享设备
复杂度	简单成熟，生态广	能力强，但依赖 API 版本和 DRA driver 生态

ResourceSlice 深入理解

ResourceSlice 是 DRA 的设备库存分片。它通常由 DRA driver 自动创建和维护，用户和平台管理员一般不手写。它把设备的结构化信息发布给 API Server，让 scheduler 能基于设备属性、容量和拓扑做匹配。

字段/概念	含义	为什么重要
driver	哪个 DRA driver 管理这批设备	避免不同厂商/驱动资源混淆
pool	资源池名称、generation、slice 数量	帮助 scheduler 判断同一资源池的库存版本
nodeName / nodeSelector	这些设备在哪些节点可用	设备必须和 Pod 调度节点匹配
devices	设备列表	可以表达每个 GPU/NPU/NIC 的名称、属性、容量
attributes	结构化属性	型号、厂商、NUMA、PCIe、NVLink、MIG profile 等
capacity	设备容量	显存、队列数、带宽等可被选择或分配

大集群中会有很多 ResourceSlice，这是预期设计。它避免把大量设备细节全部塞进 Node status，也避免用 nvidia.com/a100、nvidia.com/a100-80g-sxm-numa0 这类资源名无限膨胀。

CEL 表达式在 DRA 中的作用

CEL 是 Common Expression Language，一种安全、可嵌入的表达式语言。DRA 可以用 CEL 对 ResourceSlice 中的设备属性做过滤，例如选择 A100、显存至少 80Gi、同 NUMA 或带特定 NVLink fabric 的设备。

selectors:
- cel:
    expression: "device.attributes['model'].string == 'A100' && device.capacity['memory'].quantity >= quantity('80Gi')"

面试回答要点：CEL 的价值是把“申请某个资源名”升级为“基于结构化设备属性做查询”。

DRA driver 是什么

DRA driver 是 Kubernetes 侧的设备资源驱动，不是 Linux kernel driver，也不是 CUDA/NPU runtime 本身。它负责把真实硬件接入 DRA API：一边向 API Server 发布设备库存，一边在 Pod 落到节点后配合 kubelet 准备并交付设备。

职责	具体动作	对应对象/接口
设备发现	发现 GPU、NPU、DPU、FPGA、NIC 等设备，读取型号、显存、拓扑、健康状态	厂商 runtime、节点 agent
库存发布	把设备列表、属性、容量、资源池信息写入 API Server	`ResourceSlice`
分配协作	让 scheduler 能基于 ResourceClaim 选择具体设备，并把分配结果写入 claim 状态	scheduler + `ResourceClaim.status`
设备准备	Pod 绑定后在目标节点上准备设备，例如 CDI、device node、环境变量、mount、MIG/VF 配置	kubelet 调用 driver 的 prepare/unprepare
回收与健康	Pod 结束后清理设备状态，设备故障时更新可用性	driver controller / node plugin

一句话：Kubernetes 提供 DRA 框架和 API，DRA driver 负责把某类真实硬件翻译成 Kubernetes 能理解和交付的资源。

DRA 与 Device Plugin 是否冲突

模式	是否可行	说明
纯 Device Plugin	可行	成熟稳定，适合同质整卡资源
纯 DRA	可行	适合新集群或强异构设备，但依赖 driver 生态
按 node pool 共存	推荐	一部分节点继续 DP，一部分节点灰度 DRA
按设备类型共存	可行	GPU 用 DP，DPU/特殊 NIC 用 DRA，或反过来
同一物理设备同时暴露	不推荐	可能导致双重分配和资源状态不一致

DRA 排障路径

# 1. 看 DRA API 是否存在
kubectl api-resources | grep resource.k8s.io

# 2. 看是否有设备库存
kubectl get resourceslices -A

# 3. 看平台暴露了哪些设备类别
kubectl get deviceclasses

# 4. 看具体 claim 的分配状态
kubectl describe resourceclaim <claim-name>

# 5. 看 driver 组件是否运行
kubectl get pods -A | grep -i dra

如果 ResourceClaim 长期未分配，重点检查 DeviceClass 是否存在、ResourceSlice 是否发布、CEL selector 是否过严、节点可访问性是否满足、driver controller 和 node plugin 是否正常。

面试高频追问：默认展示版

问题	回答要点	可继续展开
ResourceSlice 是谁创建的？	通常由 DRA driver 自动创建和维护，用户一般不手写	driver 根据节点、资源池、设备类型和更新粒度做分片
大集群会不会有很多 ResourceSlice？	会，而且这是预期设计；目的是避免 Node 对象膨胀和资源名爆炸	代价是 API Server / scheduler watch 对象更多，需要控制分片和更新频率
DRA 和 Device Plugin 冲突吗？	集群层面可以共存，同一物理设备不能双重暴露	推荐按 node pool、设备类型或灰度资源池隔离
K8s 中怎么使用 MPS / Time Slicing？	通过 NVIDIA Device Plugin / GPU Operator 配置 sharing 和 replicas，把物理 GPU 暴露成多个逻辑 slot	ConfigMap、`nvidia.com/gpu.shared`、隔离边界、监控归因
`nvidia.com/a100` 已能表达卡型，DRA 价值在哪里？	资源名编码只能解决简单分类，DRA 可表达结构化属性、容量、拓扑和共享关系	显存、NVLink、NUMA、MIG profile、健康状态都适合放进 ResourceSlice
DRA driver 和 Linux driver 是一回事吗？	不是。Linux driver / CUDA / NPU runtime 管底层硬件，DRA driver 管 Kubernetes 资源发现、库存发布和设备交付	面试中要说清楚 controller、node plugin、prepare/unprepare 的边界
国产 GPU/NPU 是否有 DRA driver？	公开成熟度要谨慎判断；多数生态更常见的是 Device Plugin、Operator、vGPU 或 HAMi 等方案	判断真 DRA 看是否使用 `resource.k8s.io`、ResourceSlice、DeviceClass、ResourceClaim

AI Infra GPU / DRA 高频问答

本模块的问答按“概念 → 作用 → 链路/排查 → 面试口径”组织，避免只背一段结论。

Q: GPU Device Plugin 和普通调度有什么关系？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. Device Plugin 的概念

Device Plugin 是节点侧插件，负责发现 GPU/NPU 等设备，并通过 gRPC 向 kubelet 注册扩展资源。

2. 对 scheduler 的作用

kubelet 会把扩展资源数量写入 Node capacity/allocatable，scheduler 根据 Pod limits 和 Node allocatable 做过滤。

3. 对 kubelet 的作用

Pod 绑定到节点后，kubelet 调用 Device Plugin Allocate，拿到 device id、环境变量、mount、CDI 等设备交付信息。

4. 边界

Device Plugin 让 K8s 能看到和交付设备，但默认调度器主要看到资源名和数量，不理解完整显存、拓扑和共享关系。

面试口径：Device Plugin 负责设备发现和节点侧交付，scheduler 只基于 kubelet 上报的扩展资源数量做普通调度。

Q: Kubernetes 中如何使用 MPS 和 Time Slicing 共享 GPU？

回答思路：先说不是改 scheduler，再说 Device Plugin / GPU Operator 的资源上报方式，最后补充两者区别和生产风险。

1. 落地方式

通常通过 NVIDIA Device Plugin 或 GPU Operator 配置 sharing。管理员在 ConfigMap 中配置 sharing.timeSlicing 或 sharing.mps，并为 nvidia.com/gpu 设置 replicas。

2. K8s 看到什么

如果一张 GPU 配成 replicas: 4，kubelet 上报后 scheduler 会看到 4 个逻辑 GPU slot；如果启用 renameByDefault，Pod 通常申请 nvidia.com/gpu.shared: 1。

3. 两者区别

Time Slicing 是多个 Pod 按时间片轮流使用 GPU，配置简单但隔离弱；MPS 是多个 CUDA 进程通过 MPS daemon 并发共享 GPU，能减少上下文切换并做一定资源控制，但仍不是硬隔离。

4. 生产注意

共享 GPU 不能当作 MIG。要关注显存 OOM、P99 抖动、DCGM 监控归因限制、过度超卖和不同 workload 之间的干扰。

面试口径：K8s 调度的是 Device Plugin 上报的逻辑 GPU slot，Time Slicing 负责轮流用，MPS 负责多 CUDA 进程并发共享，二者都不等于硬件级隔离。

Q: nvidia.com/a100、nvidia.com/v100 不也是 Device Plugin 实现的吗？那 DRA 价值在哪里？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 它确实可以做到

Device Plugin 可以把不同卡型编码成不同扩展资源名，例如 nvidia.com/a100、nvidia.com/v100。

2. 资源名编码的问题

当还要表达显存大小、MIG profile、NUMA、NVLink、PCIe/SXM、健康状态、共享关系时，资源名和 label 会组合爆炸。

3. DRA 的价值

DRA 用 ResourceSlice 发布结构化设备属性，用 ResourceClaim 和 CEL 表达需求，让 scheduler 做设备级匹配。

4. 适用边界

简单同质整卡分配继续用 Device Plugin 就够；复杂异构、共享、拓扑感知场景更适合 DRA。

面试口径：Device Plugin 能表达简单卡型，DRA 的价值是结构化表达设备属性、容量、拓扑和共享关系。

Q: ResourceSlice 是谁创建的？大集群会不会很多？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 谁创建

ResourceSlice 通常由 DRA driver 的 controller 或节点组件自动创建和维护，用户一般不手写。

2. 表达什么

它表达设备库存分片，包括 driver、pool、可访问节点、设备列表、attributes、capacity 等结构化信息。

3. 大集群数量

大集群会有很多 ResourceSlice，这是设计预期，用来避免把大量设备细节塞进 Node status。

4. 治理点

需要控制分片粒度、更新频率、对象大小和 watch 压力，否则会给 API Server 和 scheduler 带来额外负担。

面试口径：ResourceSlice 由 DRA driver 维护，大集群很多是正常的，关键是控制分片和更新频率。

Q: CEL 表达式在 DRA 中怎么理解？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. CEL 是什么

CEL 是 Common Expression Language，一种安全可嵌入的表达式语言，适合在 Kubernetes API 中做轻量条件判断。

2. 在 DRA 中的作用

DRA 可以用 CEL 基于设备属性过滤候选设备，例如型号、显存、NUMA、NVLink fabric、厂商等。

3. 和资源名的区别

传统方式是“申请某个资源名”，CEL 是“查询满足结构化条件的设备”，表达能力更强。

4. 注意点

表达式过复杂或条件过严会导致匹配失败，生产上要配合 DeviceClass、ResourceSlice 和调度日志排查。

面试口径：CEL 让 DRA 从申请固定资源名升级为按结构化设备属性做筛选。

Q: DRA 和 Device Plugin 能不能同时使用？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 集群层面

可以共存，例如一批节点继续使用 Device Plugin，另一批节点灰度 DRA。

2. 设备层面

同一块物理设备不建议同时由 DP 和 DRA 暴露，否则可能出现双重分配和状态不一致。

3. 推荐方式

按 node pool、设备类型、业务队列或灰度资源池隔离，逐步验证 DRA 的调度、prepare、回收和监控。

4. 迁移策略

先低风险业务灰度，再迁移复杂异构设备；保留回滚路径和资源命名隔离。

面试口径：DP 和 DRA 可以共存，但同一物理设备不能双重暴露，推荐按节点池或设备类型隔离迁移。

Q: DRA driver 是什么？如何获取？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 概念

DRA driver 是 Kubernetes 侧设备资源驱动，不是 Linux kernel driver，也不是 CUDA/NPU runtime。

2. 作用

它负责发现设备、发布 ResourceSlice、协助 ResourceClaim 分配，并在 Pod 落到节点后 prepare/unprepare 设备。

3. 组成

通常包含 controller、node plugin、CRD/Helm chart/Operator 等组件，具体形态由厂商或社区实现。

4. 获取方式

一般来自硬件厂商、云平台或社区项目；是否成熟要看它是否支持 resource.k8s.io API、ResourceSlice、DeviceClass、ResourceClaim 和 kubelet prepare/unprepare。

面试口径：DRA driver 把真实硬件翻译成 Kubernetes DRA 资源，来源通常是厂商或社区组件。

Q: 国产 GPU/NPU 厂商有没有 DRA driver，面试怎么回答？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 谨慎态度

不要武断说都有或都没有，DRA 生态仍在演进，公开成熟度需要看具体厂商、版本和项目。

2. 常见现状

很多国产 GPU/NPU 生态更常见的是 Device Plugin、Operator、vGPU、HAMi 或厂商自定义调度方案。

3. 判断标准

看是否使用 resource.k8s.io API，是否发布 ResourceSlice、DeviceClass、ResourceClaim，是否支持 kubelet prepare/unprepare。

4. 面试补充

可以说“如果没有成熟 DRA driver，生产上通常先用 Device Plugin/Operator 接入，再通过 scheduler plugin、label、拓扑信息做增强”。

面试口径：国产 GPU/NPU 是否有成熟 DRA driver 要按公开实现判断，不能泛化；判断标准是是否完整使用 DRA API 和设备交付链路。

Q: 如何从 Device Plugin 平滑迁移到 DRA？

回答思路：先说概念和作用，再按链路或排查维度展开，最后给一句面试总结。

1. 先隔离资源池

不要在同一批物理设备上同时开放 DP 和 DRA，先建设独立 node pool 或灰度队列。

2. 部署 DRA 组件

部署 DRA driver，确认 DeviceClass、ResourceSlice、ResourceClaim 等 API 对象正常生成和更新。

3. 灰度业务

选择少量训练任务通过 ResourceClaim 接入，验证调度、prepare、容器注入、监控、回收和失败恢复。

4. 逐步迁移

按设备类型、业务队列或团队逐步迁移，保留 DP 回滚路径，并防止双重分配。

面试口径：迁移 DRA 要隔离节点池、灰度验证资源申请和设备交付链路，不能一上来混用同一批设备。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。

内容模块

Operator 与 CRD

精通★☆☆⏱ 20 min

一句话结论

Operator = CRD + Controller：CRD 负责把领域对象注册成 Kubernetes API，Operator 通过幂等 Reconcile 把对象的期望状态持续推进到实际状态。

复习定位

维度	内容
所属模块	Kubernetes 核心
章节类型	系统类
解决问题	单独掌握 CRD、Operator、controller-runtime、Reconcile、Finalizer、OwnerReference、Status Conditions 等平台工程核心能力。
面试抓手	回答时强调 schema、spec/status 分离、幂等 reconcile、finalizer 清理和 owner reference 生命周期。

阅读路径

先区分 CRD 和 Operator：CRD 是对象，Operator 是行为。
再看 controller-runtime 如何组织 Reconcile、cache、client、watch 和 webhook。
最后用 TrainingJob / AIJob 这类场景说明如何设计领域对象和生命周期。

为什么 Operator 应该单独学

Operator 是 Kubernetes 扩展体系里最常被深挖的一类问题。它不只是"写个 controller"，而是要把领域对象、状态机、失败恢复、升级回滚和可观测性都建模清楚。AI Infra 里的 TrainingJob、AIJob、RayCluster、InferenceService、GPU 资源画像，都很适合用 Operator 表达。

概念	一句话	面试边界
CRD	给 Kubernetes 增加一种新的 API 对象	只有数据和 schema，没有行为
Controller	watch 对象变化并执行 reconcile	持续让实际状态逼近期望状态
Operator	CRD + Controller + 运维知识	把业务生命周期和故障恢复代码化

CRD：往 K8s 里加一种新的 API 对象

CRD（CustomResourceDefinition）就是"我想往集群里多加一种 API 对象"。注册之后，kubectl get xxx 立刻可用，对象也走 API Server / etcd 的标准链路。但 CRD 只是声明 schema，没有控制器它就只是一份结构化数据。

关键字段	作用	面试关注点
`group / version / kind`	API 路径，例如 `training.example.com/v1alpha1, AIJob`	避免和已有 group 冲突，前期用 v1alpha1
`scope`	Namespaced 还是 Cluster	大部分业务对象 Namespaced，节点级 / 集群级才用 Cluster
OpenAPI v3 schema	校验字段类型、必填、枚举	没写 schema 字段会被丢弃；要尽量严格
`subresources.status`	分离 spec 和 status 写权限	controller 只该写 status，用户只该写 spec
`subresources.scale`	支持 `kubectl scale` 和 HPA	需要暴露 replicas 字段
`additionalPrinterColumns`	自定义 `kubectl get` 列	用户体验细节
多版本 + conversion	v1alpha1 → v1beta1 → v1 演进	需要 conversion webhook 或 None 策略

对比	ConfigMap / Annotation	CRD
类型校验	无	OpenAPI schema 校验
RBAC 粒度	所有 ConfigMap 是一类	每种 CRD 是独立资源，单独授权
watch 语义	所有 ConfigMap 在一个 watch	每个 CR 独立 watch，scale 更好
语义	"配置"	"领域对象"，可以建 controller

面试口径：CRD 是给 K8s 加新对象，schema + status 子资源 + 多版本 conversion 是工程化要点；CRD 本身只是声明，要靠 Operator 给它注入行为。

CRD 版本演进：v1alpha1 → v1beta1 → v1

CRD 版本演进不是简单改 apiVersion。面试官问这个点时，通常想看你是否理解 API 兼容性、served / storage、conversion webhook 和存量对象迁移。

阶段	语义	工程承诺
`v1alpha1`	试验版	字段和语义可能变化，兼容性承诺弱
`v1beta1`	相对稳定版	字段基本稳定，开始认真处理兼容和迁移
`v1`	稳定版	强兼容承诺，不能随意删除字段或改变字段语义

字段	含义	面试重点
`served`	这个版本是否对外提供 API 访问	老客户端还在用旧版本时要保持 `served: true`
`storage`	etcd 中对象实际存储使用哪个版本	只能有一个版本 `storage: true`
conversion webhook	不同版本 schema 不兼容时的转换逻辑	字段改名、拆分、合并时必须考虑信息是否丢失

spec:
  versions:
    - name: v1alpha1
      served: true
      storage: false
    - name: v1beta1
      served: true
      storage: true
    - name: v1
      served: false
      storage: false

一句话：可以多个版本同时 served，但只能一个版本 storage；字段结构变化时用 conversion webhook 保护老对象和老客户端。

版本升级流程：以 AIJob 为例

假设 v1alpha1 里是扁平字段，后来 v1beta1 想改成结构化字段：

# v1alpha1
spec:
  gpuCount: 8
  modelName: resnet50

# v1beta1
spec:
  resources:
    gpu:
      count: 8
  workload:
    model: resnet50

步骤	动作	原因
1	新增 `v1beta1`，保留 `v1alpha1 served=true`	老客户端和老 YAML 还能继续用
2	选择 `v1beta1 storage=true`	新写入对象统一存新版本
3	实现 conversion webhook	把 `gpuCount` 映射到 `resources.gpu.count`
4	controller 内部使用 hub version	业务逻辑不感知多个外部 API 版本
5	迁移存量对象	切 storage version 不会自动重写 etcd 里的所有旧对象
6	观测旧版本访问量	确认没有老客户端后再下线旧版本
7	将 `v1alpha1 served=false`，最终稳定到 `v1`	完成兼容窗口后的清理

面试口径：先多版本共存，再 conversion，再 storage migration，最后下线旧 served version；不能直接删旧字段。

Operator 模式：把运维知识代码化

Operator = CRD + Controller。设计 Operator 的本质是回答："给我一份期望状态（spec），我要怎么不断地把世界（status）调成那样？"这就是 Reconcile 循环。

概念	作用	面试关注点
Reconcile 循环	对每个 CR 反复执行"看现状 → 算差异 → 操作 → 写 status"	必须幂等，能容忍重复触发
Informer / Workqueue	List/Watch 缓存 + 限速队列	避免直接打 API Server
Owner Reference	子对象指向父 CR	父 CR 删除时级联删除子对象（GC）
Finalizer	删除前的 cleanup hook	常见用法：先回收云资源再让对象真正删除
Status conditions	多维度状态（Ready / Progressing / Degraded）	不要把所有状态压成一个 phase 字符串
Leader election	多副本只让一个 reconcile	用 Lease 对象
事件 record	给用户可见的反馈	`kubectl describe` 能看到

层级	OperatorHub 推荐的成熟度
Level 1 Basic Install	装得上、跑得起来
Level 2 Seamless Upgrades	支持升级，不丢数据
Level 3 Full Lifecycle	备份 / 故障恢复 / 配置变更
Level 4 Deep Insights	提供监控指标、告警
Level 5 Auto Pilot	自愈、自动 scale、自动调参

面试口径：Operator = CRD + 幂等 Reconcile；从 install 到 auto-pilot 共 5 个成熟度等级，AI 训练平台的目标至少是 Level 3。

controller-runtime：写 Operator 的标准库

kubebuilder / Operator SDK 都是基于 controller-runtime 的脚手架。它把 Informer、Workqueue、Manager、Webhook 都封装好了，让开发者主要关注 Reconcile 函数。

组件	作用
`Manager`	管 leader election、metrics、health、shared cache 和多个 controller 的生命周期
`Cache`	每个 GVK 一个 informer，Reconcile 读缓存而不是直连 API Server
`Client`	读用 cache，写直连 API Server
`Predicate`	过滤事件，避免无意义 reconcile
`Builder`	声明"我要 watch 哪些资源、Owns 哪些子对象"
`Webhook`	同进程跑 admission / conversion / defaulting webhook

常见坑	说明
读到旧缓存	cache 是异步同步，写完立刻 reconcile 可能读不到自己的写入；要么重新入队，要么用 no-cache client
无限 reconcile	每次 update 都触发新事件，要在 spec 没变时不更新对象
Status 和 Spec 一起写	违反 status 子资源语义，建议分两次 update
finalizer 写错	不能正确退出会让对象永远 Terminating
多 controller 写同一对象	易冲突，要明确 owner / 字段所有权

AIJob Operator 设计抓手

如果面试官让你设计一个 AI 训练 Operator，不要只说"创建 Pod"。要围绕任务语义和生命周期展开。

设计点	应该包含什么	为什么重要
Spec	framework、role/replica、GPU 资源、队列、minAvailable、checkpoint、容错策略	表达训练任务，而不是简单包装 PodTemplate
Status	phase、conditions、ready/failed workers、reason、start/finish time、predictionRef	用户排查和平台自动化都依赖 status
子对象	PodGroup / Pods / Service / ConfigMap / PredictionResult	通过 OwnerReference 做生命周期管理
Finalizer	删除前清理外部 checkpoint、队列占用、临时资源	避免外部资源泄漏
Reconcile	创建缺失对象、修复漂移、处理失败重试、更新 status	保证最终一致和自愈

Operator 与 CRD 高频问答

Q: CRD 和 ConfigMap 都能存配置，为什么还要 CRD？

回答思路：从校验、RBAC、watch、语义四个维度比较。

1. 类型校验

ConfigMap 没有 schema，错字段悄悄过；CRD 有 OpenAPI schema，错字段直接被拒。

2. RBAC 粒度

所有 ConfigMap 是一种资源，难做"只允许改训练任务但不能改其他配置"；CRD 每种是独立资源，可以单独授权。

3. watch 与扩展性

所有 ConfigMap 在同一个 informer，对象多了相互干扰；CRD 每种独立 watch、独立 cache，扩展性更好。

4. 语义与控制器

ConfigMap 表达"配置"；CRD 表达"领域对象"，可以挂自己的 Operator 跑 reconcile，业务语义清晰。

面试口径：CRD 不是为了"放得下"，而是为了"管得住"：schema、RBAC、watch、controller 全部独立。

Q: Operator 的 Reconcile 为什么必须幂等？

回答思路：从触发模型反推。

1. 重复触发是常态

Reconcile 由 watch 事件、resync 周期、自身 update、错误重入队等触发，同一个对象会被反复 reconcile。

2. 幂等的含义

同一 spec + 同一现状跑一次和跑十次结果一致；不能"已经创建子对象了再创建一次会冲突"。

3. 实现要点

用 GET + 比较 + Update/Patch；创建子对象时用 controllerutil.CreateOrUpdate；写状态前看是否真的变了再写。

4. 反模式

每次 reconcile 都改 spec → 触发新事件 → 再次 reconcile → 死循环；要严格区分谁写 spec 谁写 status。

面试口径：K8s 的控制循环是"事件多、可能丢、可能重复"，所以 Reconcile 必须无条件幂等，并且 spec / status 写权严格分离。

Q: 什么时候不该用 Operator？

回答思路：避免"什么都包成 Operator"的过度工程化。

1. 一次性脚本

就是初始化建几个对象，写个 Helm hook 或 Job 即可，不需要长期 reconcile。

2. 没有持续运维语义

对象创建后不需要持续守护、不需要根据外部状态调节，CRD 没意义。

3. 跨集群编排

跨集群编排是 Fleet / ApplicationSet 的职责，不是单集群 Operator 的舞台。

4. 替代方案足够

静态策略用 VAP，资源调度用 scheduler plugin，发布用 GitOps，能不写 controller 就不写。

面试口径：Operator 是为了"持续运维知识代码化"。一次性、无外部状态、跨集群这三类场景，要优先选别的扩展点。

关联模块

Workload 与 Controller：理解 controller / reconcile 的基础。
Scheduler 插件与扩展：理解调度逻辑不应该塞进 Operator。
AI Infra：GPU / 批调度 / DRA：理解 AIJob、PodGroup、GPU 资源语义。
扩展与工程化：理解 Operator 如何被 Helm、Kustomize、GitOps 部署和发布。

内容模块

扩展与工程化

精通★★☆⏱ 18 min

一句话结论

K8S 工程化要区分“扩展能力”和“交付能力”：CRD / Operator 负责建模和控制循环，Helm / Kustomize / GitOps / 渐进式发布负责把这些对象安全、可审计地交付到集群。

复习定位

维度	内容
所属模块	Kubernetes 核心
章节类型	系统类
解决问题	梳理 Helm、Kustomize、GitOps、ArgoCD/Flux、渐进式发布，以及不同 Kubernetes 扩展点如何选型。
面试抓手	Operator 与 CRD 已拆到单独章节；本节重点讲工程化交付、发布回滚和扩展点选型。

阅读路径

先看 Helm / Kustomize：解决 YAML 参数化和多环境差异。
再看 GitOps：解决集群状态审计、同步和漂移修复。
最后看扩展点选型：不同需求应该接 CRD、Webhook、Scheduler Plugin、DRA、CSI、CNI 还是 GitOps。

本 Tab 想说清楚什么

Kubernetes 平台工程不只是写 YAML，而是要把对象建模、配置渲染、环境差异、发布回滚、审计和漂移修复串起来。Operator 与 CRD 的设计细节已经拆到“Operator 与 CRD”章节；本节只保留工程化交付和扩展点选型。

主题	解决什么问题	本节重点
Helm	如何把一组 YAML 参数化、版本化发布	Chart、values、release、upgrade / rollback
Kustomize	如何维护 dev / staging / prod 的环境差异	base + overlay、patch、images、replicas
GitOps	如何把集群状态纳入 Git 审计和自动同步	ArgoCD / Flux、pull 模型、drift correction
渐进式发布	如何降低发布风险	Deployment rolling update、Argo Rollouts、Flagger
扩展点选型	什么需求应该接哪个 Kubernetes 扩展点	CRD/Operator、Webhook、Scheduler Plugin、DRA、CSI、CNI

Helm：包管理与版本化的 release

Helm 把一组 YAML 模板打包成 Chart，渲染时用 values 注入参数；安装后会在集群里创建一个 release，可以 upgrade / rollback / uninstall。它解决"YAML 反复抄"和"我装的是哪个版本"。

对象	作用
Chart	包含 templates / values.yaml / Chart.yaml
values.yaml	默认参数，用户可以覆盖
helpers (_helpers.tpl)	命名前缀、label 标准化等模板片段
release	一次安装的实例，记录 revision，支持回滚
hooks	install / upgrade / delete 前后的钩子任务
dependencies	子 chart，例如装 Operator 时同时装 CRD chart

能力	Helm	Kustomize
核心思路	模板 + 参数	原生 YAML + Overlay 补丁
语法	Go template，比较"密"	纯 YAML，结构清晰
版本管理	有 release / revision	没有，靠 Git 提交
升级 / 回滚	`helm upgrade / rollback`	靠 GitOps 工具
条件分支	强（`{{ if }}`）	弱，靠多 overlay
典型场景	分发可参数化的中间件	同一份基线，差异化部署到 dev/staging/prod
组合用法	Chart 内部用 Helm 模板，外部环境差异用 Kustomize overlay：`helm template ... \| kustomize build`

Kustomize：base + overlay 的纯 YAML 工程化

Kustomize 思路是不引入模板语言：先有一份纯 YAML（base），各环境用 overlay 描述差异（patch、replicas、image、namespace、labels）。

原语	作用
`resources`	本 layer 引用的 YAML 文件 / 子目录
`namespace / commonLabels / commonAnnotations`	批量改本层所有对象
`images`	替换镜像 tag
`replicas`	调整 replica 数
`patches`	strategic merge / JSON patch 改字段
`configMapGenerator / secretGenerator`	从文件 / literal 生成 ConfigMap / Secret，附带 hash 后缀
`components`	可复用的"功能片段"

什么时候选谁？

分发给外部用户的中间件 / Operator用 Helm（要参数化、要 release 概念）；自家平台多环境部署用 Kustomize（要清晰的 diff）；两者也能组合：Helm 渲染出来的 YAML 再用 Kustomize 做环境差异化。

GitOps：把"集群状态"也写进 Git

GitOps 不是工具，是工作模型：Git 是唯一真相，集群状态由 Git 持续 reconcile 出来。所有变更都走 PR + Review，不再人肉 kubectl apply。

原则	含义
声明式	所有期望状态用声明式 YAML 表达
版本化 + 不可变	Git 提交即审计；同一 commit 在不同时间渲染结果一致
自动化拉取	Agent 在集群里持续 pull / sync
持续 reconcile	偏离期望状态会被自动纠回（drift detection）

对比	ArgoCD	Flux
架构	有 UI server + 多 controller	多个 controller（source / kustomize / helm / notification）
UI	原生 Web UI 强	较轻，常配合 Weave GitOps UI
多集群	ApplicationSet + cluster generator	Flux 多 cluster bootstrap
Helm 支持	支持（渲染或 chart）	支持（HelmRelease 控制器）
Kustomize 支持	原生	原生（Kustomization controller）
渐进交付	结合 Argo Rollouts	结合 Flagger
可观测	UI 直接看 sync 状态、diff	主要靠 metrics + CLI

面试口径：GitOps = "Git 是真相 + 集群里有 agent 持续 sync + 偏离自动纠回"。ArgoCD UI 友好、生态丰富，Flux 更轻量、controller 拼装灵活；选谁看团队偏好和多集群规模。

渐进式发布与 K8s 原生回滚

真正生产里发布从来不是 kubectl apply 一把梭。要分清"K8s 自带的滚动发布"和"渐进式发布工具（Argo Rollouts / Flagger）"的边界。

能力	K8s 原生 Deployment	Argo Rollouts / Flagger
滚动更新	maxSurge / maxUnavailable	支持，且每步可以手动审批
金丝雀 / 蓝绿	需要拆两个 Service，复杂	原生 Canary / BlueGreen 策略
自动 metrics 分析	无	用 Prometheus / Datadog 做发布门禁
回滚	`kubectl rollout undo` 回到上一 revision	失败自动回滚 + 审计
结合 Service Mesh	需要自己写规则	原生支持 Istio / Linkerd / SMI

面试口径

普通业务用 Deployment + RollingUpdate 已经够；对外重要服务建议用 Argo Rollouts 做 canary + metrics 门禁，把"判断这次发布健康吗"从人工眼神切换成自动化指标。

扩展点全景图：什么需求接哪个扩展点

需求	该用哪个扩展点	原因
新增一种业务对象（AIJob、Tenant）	CRD + Operator	声明式建模业务实体
静态准入策略（禁特权、强制 label）	ValidatingAdmissionPolicy（CEL）	无需部署 webhook，毫秒级
动态准入（查外部系统）	Validating / Mutating Webhook	能跑任意逻辑
调度策略（拓扑、组调度、Backfill）	Scheduler Plugin（Filter / Score / PreBind）	调度内核内嵌扩展
新种类设备 / 资源	DRA（DeviceClass + ResourceClaim）	替代 Device Plugin，支持复杂 attributes
新存储后端	CSI Driver	统一卷接口
新网络方案	CNI Plugin	Pod 网络模型扩展
聚合 API（自己提供 K8s 风格 API）	API Aggregation Layer	复用 RBAC、kubectl，但服务自管
跨集群同步对象	Operator + GitOps（ArgoCD ApplicationSet）	避免一致性靠人
把 YAML 工程化	Helm + Kustomize	分别解决参数化和环境 overlay

面试口径：选扩展点先问"我是要加一个对象、还是改调度、还是改网络/存储/准入"，然后选最贴合的扩展点。能用内置（VAP、Scheduler Plugin、DRA）就别上独立 webhook / sidecar，控制面稳定性更重要。

扩展与工程化高频问答

Q: Helm 和 Kustomize 怎么选？能一起用吗？

回答思路：从分发场景和组合用法回答。

1. 各自的强项

Helm 强在参数化分发，适合发布给外部用户的中间件；Kustomize 强在多环境 overlay，适合自家平台 dev/staging/prod 差异化部署。

2. 各自的痛点

Helm 模板语法重，YAML 一旦复杂就难以审阅；Kustomize 没有 release 概念，回滚要靠 Git。

3. 组合用法

常见做法：第三方 Operator 用 Helm 渲染，再用 Kustomize 做环境差异；或者 ArgoCD Application 同时声明 Helm + Kustomize。

4. 结论

没有银弹。GitOps 落地里，"Helm 做包，Kustomize 做层"是非常常见的搭配。

面试口径：Helm 解决参数化和分发，Kustomize 解决环境 overlay；生产里两者经常组合，Helm 渲染 + Kustomize 差异化。

Q: 什么是 GitOps？为什么是 pull 模型？

回答思路：从动机讲到实现，把 pull 的理由说清楚。

1. 动机

"集群状态"必须可审计、可回放、可恢复。Git 是天然的版本化、有 Review 流程的真相。

2. Pull 模型

集群里跑 agent（ArgoCD / Flux），定期从 Git 拉最新期望状态并 reconcile。CI 不需要拥有集群凭据，安全边界更小。

3. Drift 自动纠回

有人手工 kubectl apply 改了对象，agent 会检测到并恢复成 Git 中的版本，强制变更走 PR。

4. 配套

多集群用 ApplicationSet / Flux multi-cluster；渐进式发布配 Argo Rollouts 或 Flagger；Secret 配 SealedSecrets / SOPS / External Secrets。

面试口径：GitOps = Git 是真相 + 集群 agent 持续 pull + drift 自动纠回；pull 模型让 CI 系统不持有集群凭据，更安全。

关联模块

GPU 硬件与资源共享：提供 SM、HBM、NVLink、MIG/MPS、利用率诊断等底层直觉。
LLM 推理系统：提供 Prefill/Decode、KV Cache、Serving Engine 和推理优化语境。
Kubernetes 核心：提供调度、资源模型、控制器和扩展机制。
分布式训练 / 调度与集群：提供多卡通信、队列、公平性、拓扑和容错背景。