第3章 Kubernetes 核心概念与 Pod 生命周期：Pod、Deployment、StatefulSet、DaemonSet 高频问题
Pod 是 Kubernetes 最小调度单元，生命周期状态机与控制器特性是面试必考。本章聚焦三大控制器（Deployment、StatefulSet、DaemonSet）的底层原理、适用场景与发布策略，帮你建立可迁移的回答框架。
| 控制器 | 副本管理 | 更新策略 | 存储 | 网络标识 | 典型场景 |
|---|---|---|---|---|---|
| Deployment | ReplicaSet，可指定副本数 | 滚动更新、回滚（maxSurge/maxUnavailable） | 不支持持久卷自动绑定 | Pod 名随机，无稳定网络标识 | 无状态服务（API、Web 前端） |
| StatefulSet | 有序创建/删除、有序滚动更新 | OnDelete 或 RollingUpdate（分区） | 支持 PVC 模板，持久存储 | Pod 名有序（name-0…），稳定 DNS |
有状态服务（数据库、MQ、ZooKeeper） |
| DaemonSet | 每个节点运行一个 Pod | OnDelete 或 RollingUpdate | 通常使用 hostPath 或 emptyDir | Pod 名与节点相关 | 日志收集、节点监控、CNI 组件 |
问题：请详细描述 Pod 的生命周期状态及转换过程。
🧐 考察点：Pod 状态机理解、状态转换条件、容器重启策略对生命周期的影响。
- 列出 Pod 的五个核心状态：Pending、Running、Succeeded、Failed、Unknown。
- 描述每个状态的触发条件（如 Pending → 调度成功且镜像拉取完成 → Running）。
- 结合
status.conditions（PodScheduled、Initialized、Ready）细化中间状态。 - 说明容器重启策略（Always / OnFailure / Never）如何影响 Failed 后的行为。
💬 示例回答：Pod 生命周期的五种状态：Pending（调度/镜像拉取中）、Running（至少一个容器运行）、Succeeded（容器正常退出）、Failed（异常退出）、Unknown（与节点失联）。重启策略决定失联后的动作，例如 Job 用 Never，Deployment 用 Always。诊断 Pending 需查看 Events，常见原因：资源不足、PVC 未绑定、镜像拉取失败。
🔍 可能追问：Pod 一直 Pending，列举 3 种可能原因？status.conditions 中 Ready 与 ContainerReady 的区别？
⚠️ 避坑提醒：不要只背状态名称，要说清转换条件；区分 Pod 状态与容器状态（如 CrashLoopBackOff 属于容器状态，Pod 仍为 Running）。
问题：Deployment、StatefulSet、DaemonSet 三者核心区别及应用场景。
🧐 考察点：控制器设计理念、有状态/无状态区分、节点独占需求、更新策略差异。
- Deployment：无状态，副本可互换，滚动更新灵活（maxSurge/maxUnavailable）。
- StatefulSet：有状态，稳定网络标识（
sts-name-0）、有序扩缩、专用 PVC。 - DaemonSet：节点级守护，每个节点一个 Pod，适合日志/监控。
- 对比更新策略（Recreate / RollingUpdate / OnDelete）及适用条件。
💬 示例回答：Deployment 用于无状态服务（如 API），支持滚动更新与回滚。StatefulSet 用于需要稳定身份和持久存储的数据库，Pod 创建/删除顺序严格。DaemonSet 确保每个节点运行一个 Pod，如 filebeat。选择依据：是否需要状态、节点独占、Pod 身份稳定。
🔍 可能追问：StatefulSet 的 Pod 名称生成规则？如何实现有序滚动更新？DaemonSet 在云上如何处理节点自动伸缩？
⚠️ 避坑提醒：不要混淆 StatefulSet 的 Service 名称与 Pod 名称；DaemonSet 在云上因节点扩缩可能导致 Pod 频繁重建，需配合 nodeAffinity 控制。
问题：如何实现 Deployment 的金丝雀发布和蓝绿部署？
🧐 考察点：发布策略实战、Deployment 滚动更新原理、流量切换方式（Service/Ingress）。
- 金丝雀：同时维护新旧两个 Deployment，通过 Service label selector 或 Ingress 权重控制流量比例。
- 蓝绿：两套完整环境（Blue/Green），Service 通过更新
selector或切换 Ingress 后端实现全量切换。 - 基于 Deployment 自身滚动更新（
maxSurge+maxUnavailable）可实现灰度，但粒度较粗。 - 需要配合 PodDisruptionBudget 保证高可用。
💬 示例回答：金丝雀：部署新版本 Deployment（replicas=1），保留旧版本，调整 Service selector 匹配新旧 Pod，逐步增加新版本副本，监控错误率后全量切换。蓝绿：部署 Green 环境，通过修改 Service selector 从 Blue 切到 Green，回滚仅需改回。注意设置 maxSurge=25%、maxUnavailable=0。
🔍 可能追问：金丝雀如何精确控制流量比例（如 10%）？Istio 如何实现？maxSurge 和 maxUnavailable 的推荐值？
⚠️ 避坑提醒：金丝雀发布时需确保旧版本 Pod 不被 Scale down；蓝绿部署需要双倍资源；不要忽略 PDB 导致滚动中断。