第 3 章：核心概念高频面试题 —— Pod、Deployment、StatefulSet、DaemonSet 辨析与选型

本章定位：面试中 80% 的高阶题围绕工作负载控制器展开。不仅仅问“是什么”，更要求你讲清楚“为什么选”、“怎么用”以及“对比痛点”。你需要从实例特征、调度行为、存储绑定、升级策略四个维度建立比较框架。

选择工作负载控制器 4 类核心控制器 Pod 临时性 · 单实例 Deployment 无状态 · 滚动更新 StatefulSet 有状态 · 有序部署 DaemonSet 每节点一个 · 守护 ✚ 选型关键：实例特征 → 调度行为 → 存储绑定 → 升级策略

核心概念对比表

维度 Pod Deployment StatefulSet DaemonSet
实例特征临时、可替换无状态、同质有状态、唯一标识每节点一个
存储默认无持久卷需通过 PVC 共享自动分配唯一 PVC通常 hostPath
升级策略直接删除重建滚动更新、回滚按序滚动、金丝雀滚动更新
网络标识IP 不固定靠 Service固定 hostname节点 IP + 端口
应用场景测试、sidecarWeb、API 无状态数据库、分布式存储日志采集、监控 agent

📌 面试问题 1

“请从调度、存储、升级三个方面对比 Deployment 和 StatefulSet，并说明各自的核心适用场景。”

🎯 面试官考察点：是否理解有状态/无状态的本质差异；能否从资源编排视角讲清绑定关系；是否有分布式系统设计认知。
✅ 回答框架：
  1. 调度对比：Deployment 任意调度、Pod 可互换；StatefulSet 按序调度、Pod 有稳定 identity。
  2. 存储对比：Deployment 依赖 PVC 模板，Pod 重建后 PVC 需手动或通过 volumeClaimTemplates 重建；StatefulSet 自动为每个副本创建唯一 PVC，Pod 重建后重新绑定同一 PVC。
  3. 升级对比：Deployment 支持任意滚动顺序；StatefulSet 按索引逆序滚动，支持 Partition 金丝雀。
  4. 场景：Deployment 用于无状态服务（Web、API），StatefulSet 用于数据库、消息队列、ZooKeeper 等有状态服务。
📝 简短示例回答：“Deployment 将 Pod 视为可互换的 cattle，调度无顺序，存储通常共享或通过 PVC 模板但无绑定，适合无状态应用。StatefulSet 为每个 Pod 赋予稳定网络标识和独立 PV，创建/销毁按序控制，适合需要持久化数据的分布式有状态服务，如 MySQL 集群。” (约 100 字)
🔍 可能追问：
  • StatefulSet 的 Pod 名称如何生成？删除后如何恢复？
  • Deployment 能用于有状态场景吗？有哪些风险？
  • 如果必须用 Deployment 部署有状态应用，你会怎么设计存储方案？
⚠️ 避坑提醒：不要只说“一个有状态一个无状态”，必须解释“为什么 StatefulSet 能保证绑定” —— 核心是 ordinal index + PVC 模板 + headless service。避免把“Pod 名字”和“网络标识”混为一谈。

📌 面试问题 2

“DaemonSet 和 Deployment 在调度上有哪些本质区别？请举一个你使用 DaemonSet 的真实例子。”

🎯 面试官考察点：是否理解“每个节点一个”的调度语义；能否区分 nodeSelector / affinity 与默认调度；是否有生产落地经验。
✅ 回答框架：
  1. 调度本质：Deployment 由 scheduler 在可用节点中通过打分分配，可调整副本数；DaemonSet 由 DaemonSet controller 保证每个符合条件的节点运行一个 Pod，无视调度器。
  2. 节点选择：DaemonSet 通过 nodeSelector / tolerations / nodeName 筛选，默认在所有节点运行（包括 master 通过 taint 容忍）。
  3. 副本关系：Deployment 副本数与节点数无关；DaemonSet 副本数 = 匹配节点数。
  4. 案例：使用 DaemonSet 部署 Filebeat/Fluentd，采集每个节点上的容器日志并发送到 ES。
📝 简短示例回答：“DaemonSet 确保每个目标节点运行一个 Pod，无需 scheduler 干涉；而 Deployment 由 scheduler 按资源负载分配。我曾用 DaemonSet 部署 CNI 插件（Calico），保证每个节点上运行网络 agent 处理 pod 网络，快速响应节点加入。” (约 90 字)
🔍 可能追问：
  • DaemonSet 更新时，如何控制灰度？
  • 如果使用 DaemonSet 部署监控 agent，节点扩缩时如何处理？
  • DaemonSet 的 Pod 被驱逐后会怎样？
⚠️ 避坑提醒：不要先说“DaemonSet 也是实现高可用”，它本身不解决应用层高可用，只是保证覆盖。同时注意资源预留：DaemonSet 的 Pod 会占用节点资源，需配合 resource request/limit 和 PriorityClass。

📌 面试问题 3

“Pod 本身就是一个工作负载，为什么还需要 Deployment、StatefulSet、DaemonSet 这些控制器？直接创建 Pod 有哪些问题？”

🎯 面试官考察点：是否理解控制器的抽象价值；是否对 Kubernetes 声明式设计有认知；能否讲清自愈、扩缩、升级等生命周期的必要性。
✅ 回答框架：
  1. 自愈：直接创建 Pod 没有 ReplicaSet 级别的健康检查与自动重建；控制器保证期望副本数。
  2. 升级与回滚：Pod 手动删除重建无法实现滚动更新；Deployment/StatefulSet 提供版本管理。
  3. 扩缩容：Pod 无法通过 HPA 或手动调整副本；控制器与 Service 联动。
  4. 存储与网络标识：StatefulSet/DaemonSet 提供了 PVC 绑定和 stable network identity，Pod 无原生机制。
📝 简短示例回答：“直接创建 Pod 无法利用 Kubernetes 的生命周期管理。比如 Pod 所在节点宕机，控制器会自动重建；而裸 Pod 永远丢失。生产环境必须使用控制器，至少用 Deployment 管理无状态服务，否则运维成本极高。” (约 80 字)
🔍 可能追问：
  • Job 和 CronJob 与这些控制器有何不同？
  • 什么时候可以手动管理裸 Pod？（实验、调试场景）
  • 如果 Deployment 没有 readiness probe 会怎样？
⚠️ 避坑提醒：面试官可能追问“你提到了自愈，但 Pod 的 restartPolicy 也能重启”，需要区分：kubelet 重启（同一节点） vs. 控制器迁移（节点故障时 Pod 被调度到另一节点）。控制器才能处理跨节点自愈。
💡 高阶面试加分点：
  • OwnerReference：控制器通过 OwnerReference 关联 Pod，禁止手动删除受管 Pod，要讲清级联删除机制。
  • finalizer：StatefulSet 删除会等待 PVC 释放，这是面试常考细节。
  • 拓扑约束：Deployment + PodTopologySpread 可以实现跨 AZ 调度；StatefulSet 可通过 topology.kubernetes.io/zone 做局部化。
← 上一章 📖 返回目录 下一章 →