10. 面试题精选
一句话理解：本章按初/中/高三级整理 26 道 Operator 高频面试题，覆盖机制、工程、生产与 2025–2026 生态演进——每题给"考点 + 参考答案要点"，帮你把前九章的知识点串成能讲清楚的表达。
10.1 初级（概念与机制，8 题）
Q1. 用一句话解释 Operator 模式。
考点：CoreOS 定义的本质。答：Operator = CRD（自定义资源扩展 K8s API）+ 自定义 Controller（持续 watch + reconcile 的控制循环），把领域专家的运维知识编码成"永远在线、自动纠偏"的代码。它与 K8s 内置 Controller 机制同构，只是管领域对象而非通用 Pod 副本数。
Q2. Operator 和 Helm 的区别？什么时候用哪个？
考点：一次性安装 vs 持续管理。答：Helm 是模板渲染 + 一次性 apply，装完即走，不持续监控；Operator 是 CRD + 控制循环，持续自愈。要"装一次 + 参数多"用 Helm；要"长期运行 + 自动纠偏 + 领域逻辑"用 Operator。最常见组合：Helm 装 Operator，Operator 管业务。
Q3. 什么是 Reconcile 的 level-triggered？为什么不用 edge-triggered？
考点：状态 vs 事件。答：level-triggered 基于"当前全量状态"算 diff（恒温器模型）；edge-triggered 基于"发生了什么事件"（脚本模型）。level-triggered 在漏掉中间事件（网络抖动、Controller 重启）时仍能收敛，因为它每次读全量；edge-triggered 漏一个事件就永远错了。
Q4. Reconcile 的四条铁律是什么？
考点：契约。答：① level-triggered（读全量）；② 幂等（多次调和结果一致）；③ 不阻塞（单次快速返回，长等待用 RequeueAfter）；④ 乐观返回（不保证一次收敛，最终一致即可）。
Q5. For 和 Owns 的区别？
考点：Controller 装配。答：For 是主资源（watch CR 本身，事件映射到它自己）；Owns 是子资源（watch 它，事件通过 ownerReference 反查映射到 owner CR）。漏 Owns → 子资源变化收不到事件 → 自愈失效。
Q6. spec 和 status 有什么区别？谁写？
考点：声明式 API 约定。答：spec 是用户写的"期望状态"，status 是 Controller 写的"实际状态"。spec 变更 bump generation，status 不变。status 通过 /status 子资源单独写入（独立 resourceVersion），避免写 status 触发 spec 的 reconcile 死循环。
Q7. 什么是 finalizer？解决了什么问题？
考点：删除安全。答：finalizer 是 metadata.finalizers 列表里的名字；有 finalizer 的对象 delete 只设 deletionTimestamp 不真删，Controller 在 reconcile 时发现删除中就执行清理（外部资源），完成后移除 finalizer，最后一个移除时 apiserver 才真删。解决"删 CR 前必须清理 K8s 外部资源（S3/DNS/LB）"。
Q8. Owner Reference 解决什么问题？
考点：级联回收。答：让子资源和 CR 同生共死——CR 删了，K8s 垃圾回收控制器检测到 owner 被删，自动级联删子资源。和 finalizer 分工：owner reference 管 K8s 内部子资源级联，finalizer 管 K8s 外部资源清理。
10.2 中级（工程与实现，9 题）
Q9. controller-runtime 的 Manager 和 Controller 各管什么？
考点：架构分层。答：Manager 管进程生命周期——持有共享 Cache/Client、Leader Election、Metrics/Health/Webhook Server、管理所有 Controller 的启停。Controller 管单个 reconcile 循环——Source→EventHandler→Workqueue→Reconciler 流水线。一个 Manager 可挂多个 Controller。
Q10. 为什么 Controller 读资源走 Cache 而不直查 apiserver？
考点：Informer/Cache。答：① 快（本地内存）；② 不压 apiserver（频繁 reconcile 直查会打爆 apiserver）。代价是 Cache 有几秒滞后，但 level-triggered 容忍。写仍直通 apiserver。
Q11. Workqueue 的去重为什么重要？
考点：抗事件风暴。答：K8s 资源变化可能极快（一个 Deployment 短时间 spec 改 10 次），但 level-triggered 只需"调和到最新状态"一次。Workqueue 按 ns/name 去重，保证不管中间多少事件，最终只 reconcile 一次到最新——这是 level-triggered 扛住事件风暴的工程基础。
Q12. Reconcile 返回值的四种语义？
考点：Requeue。答：Result{},nil（完成等事件）；RequeueAfter:Ns,nil（N 秒后再调和，用于等 Pod ready/周期检查）；Requeue:true,nil（立即重排，少用）；任意+error（指数退避重试）。
Q13. 什么是乐观并发？Controller 怎么用它？
考点：resourceVersion。答：每个对象有 resourceVersion；update 带上"读到的"rv，若与 etcd 现存不一致 apiserver 返回 409 Conflict。Controller 读走 Cache（滞后）、写带 rv，冲突时 controller-runtime 自动退避重试——读后写的并发安全完全靠它，不用加锁。
Q14. generation 和 observedGeneration 的区别？为什么重要？
考点：版本追踪。答：generation 是 spec 每次变更 +1（status 不变）；observedGeneration 是 Controller 写进 status 的"我已处理到第 N 版"。observedGeneration == generation 说明 Controller 已响应最新 spec；不等说明"spec 改了 Controller 还没反应"——这是判断 Operator 是否跟上的关键。
Q15. Leader Election 为什么必要？机制是什么？
考点：多副本协调。答：多副本都 reconcile 会重复操作 + status 互相覆盖。Leader Election 用一个 Lease 资源做分布式锁，抢到的成为 leader 启动 Controller，其他待命；leader 心跳续约，崩溃则其他接管。和 K8s 内置 Controller Manager 机制一致。
Q16. Webhook 的三类是什么？生产要注意什么？
考点：准入控制。答：mutating（修改/设默认值）、validating（校验业务语义）、conversion（多版本 CRD 互转）。生产：webhook 是控制平面关键路径，挂了相关 CR 写不进——必须 ≥2 副本 + <1s 响应 + failurePolicy 明确 + namespaceSelector 限范围 + 证书自动轮换（过期会瘫痪集群写入）。
Q17. 怎么测试一个 Operator？
考点：测试策略。答：用 controller-runtime 的 envtest（起真实 etcd+apiserver 无 kubelet，跑真 CRD/Reconcile）做 Reconcile 单元测试；三层：单元（helper）→ envtest（端到端 reconcile）→ e2e（kind 集群含部署+升级）。重点测幂等（连续 reconcile 子资源数不变）和删除（finalizer 清理 + 级联）。
10.3 高级（生产与深度，9 题）
Q18. 一个 CR 卡在 Terminating 删除不掉，怎么排查和救？
考点：finalizer 故障。答：先 kubectl describe 看 finalizers 列表 + events，判断是哪个 finalizer 的清理逻辑失败（外部资源不可达/逻辑 bug）。若是清理永远失败且无法修，逃生口：kubectl patch <cr> -p '{"metadata":{"finalizers":[]}}' --type=merge 强制移除（警告：跳过清理，外部资源残留）。长期：清理逻辑必须可重试 + 有超时。
Q19. Operator 创建的 Deployment 被人手动改了副本数，会发生什么？
考点：漂移自愈。答：几秒内被 Operator 改回 spec 期望值——这是设计行为（level-triggered 纠偏）。因为 Deployment 是 Operator Owns 的子资源，它的变化触发 owner CR 的 reconcile，Reconciler 算出现状 ≠ 期望就 Patch 纠回。要改副本数应改 CR.spec，不是改子资源。
Q20. 怎么设计一个支持金丝雀升级的推理 Operator？
考点：AI 场景设计。答：CR spec 支持主版本 + canary 版本 + canaryTrafficPercent；Reconciler 维护两套 Deployment（stable + canary），Service 用权重或两 Service + 流量分流按比例导流；canary 的 readiness/指标达标后逐步提比例，全量后回收 stable。注意模型加载延迟——canary Pod ready 要等 /health（领域就绪）而非 TCP。
Q21. CRD 从 v1beta1 演进到 v1，怎么无损迁移？
考点：版本演进。答：① CRD 声明 v1（served, storage）+ v1beta1（served），配 conversion webhook 互转；② 只有 v1 是 storage（真正写 etcd）；③ conversion 必须无损往返（v1→v1beta1→v1 等价）；④ 等客户端改用 v1；⑤ 下线 v1beta1。webhook 要 HA + 证书自动轮换 + 充分测试。
Q22. Operator 的 reconcile_errors_total 持续增长，怎么定位？
考点：可观测排障。答：这是第一告警指标，意味着 Controller 反复失败重试。看日志（error 原因）、events（业务事件）、具体 CR 的 status.conditions。常见原因：CR 配置违反业务规则、子资源 schema 不匹配、apiserver 限流、依赖（外部 API/对象存储）不可达、代码 bug。定位后修复，errors 应回落。
Q23. 多租户 AI 平台，一个集群多个团队，Operator 怎么隔离？
考点：多租户。答：两种模式——namespace 级（每团队一 ns + 一 Operator 实例 WATCH_NAMESPACE 限定，简单但运维 N 个 Operator）或集群级（一 Operator + RBAC 严格隔离 CR 写权限，省资源）。配额用 validating webhook 编码（拦截超 GPU 配额的 CR）。工作负载用 nodeSelector/priorityClass 调度到专属节点池。
Q24. 什么场景不该用 Operator？
考点：选型判断。答：只要"装一次 + 参数多"用 Helm；"一次性流水线 DAG"用 Argo Workflow；"定时/一次性任务"用 Job/CronJob。只有"持续自愈 + 领域知识 + 多资源协同"三者俱全才值得 Operator。很多"看起来需要 Operator"的需求，Helm + readiness probe 就够了——过度工程是反模式。
Q25. Mutating Admission Policy（MAP）能替代 mutating webhook 吗？边界在哪？
考点：2025–2026 准入控制演进。答：MAP 在 K8s 1.36 GA，用声明式 CEL 在 apiserver 进程内做对象变更——无 webhook server、无 TLS 证书、无网络跳、延迟微秒级，天然免去了 webhook 的高可用/证书/failurePolicy 负担。但边界清晰：只适合单对象、CEL 可表达的简单变更（设默认值、注入 label、按条件改字段）；跨对象关联、查外部系统、复杂业务规则仍需 webhook。实践决策顺序：CRD schema default: → MAP → webhook。
Q26. 一个 Operator 管几千个推理服务 CR，故障恢复有 SLA，怎么保证恢复速度？
考点：大规模调和的工程手段。答：三个层面——① 优先级队列：controller-runtime v0.23 起默认开启，故障恢复中的 CR 返回 Result{Priority: 高} 插队，闲时同步任务给低优先级；② 并发度：调大 MaxConcurrentReconciles（按 reconcile 耗时和 apiserver 容量压测）；③ 限流与退避：自定义 RateLimiter 防 apiserver 风暴，区分"可重试错误"（退避）和"业务终态"（如配额不足用 TerminalError 不再重试）。辅以 workqueue_depth 告警监控积压。
本章小结
- 初级抓本质：Operator = CRD + 控制循环、与 Helm 互补、Reconcile 四铁律、For/Owns、spec/status、finalizer/owner。
- 中级抓工程：Manager/Controller 分层、Cache 读写分离、Workqueue 去重、Requeue 四语义、乐观并发、generation 追踪、Leader Election、Webhook 三类、envtest 测试。
- 高级抓生产：finalizer 卡删除排查、漂移自愈、金丝雀设计、CRD 版本演进、reconcile_errors 排障、多租户隔离、选型判断；以及 2025–2026 演进——MAP 与 webhook 的边界、大规模 CR 的优先级队列与并发调优。
参考来源