2. Kubernetes Deployment 基础回顾
在深入故障域隔离与黄金路径边界验证之前，必须重新夯实 Deployment 的核心运行机制。Deployment 是 Kubernetes 中声明式管理无状态工作负载的顶层控制器，它通过 ReplicaSet 实现 Pod 副本的期望状态维持，并通过 滚动更新 完成版本切换。本节将拆解这三个层次，为后续的故障域建模提供精确的语义基础。
2.1 Deployment 核心概念与层级关系
Deployment 并不直接管理 Pod，而是通过 ReplicaSet 间接控制。这种分层设计使得版本回滚、扩缩容、更新策略可以独立作用于不同层级。下图展示了 Deployment → ReplicaSet → Pod 的三层控制关系：
spec.replicas 直接作用于当前活跃的 ReplicaSet。当触发更新时，旧 ReplicaSet 的副本数逐渐归零，新 ReplicaSet 的副本数逐渐上升。这种“双 ReplicaSet 共存”窗口期是滚动更新故障域分析的核心场景。
2.2 ReplicaSet：副本保障与选择器机制
ReplicaSet 的核心职责是确保任意时刻都有指定数量的 Pod 副本处于运行状态。它通过 Label Selector 匹配 Pod，并利用 OwnerReference 建立从属关系。
| 属性 | 说明 | 故障域影响 |
|---|---|---|
spec.replicas |
期望的 Pod 副本数量 | 决定了故障域内 Pod 分布密度 |
spec.selector.matchLabels |
用于匹配 Pod 的标签键值对 | 必须与 Pod template 标签严格一致，否则 ReplicaSet 无法接管 Pod |
spec.template |
Pod 模板，定义容器、资源、调度约束 | 模板中的 topologySpreadConstraints 和 affinity 直接影响故障域隔离效果 |
status.availableReplicas |
当前就绪的副本数 | 滚动更新时用于判断是否达到期望水位 |
matchLabels 一旦创建不可修改。如果误配标签，会导致 ReplicaSet 无法匹配任何 Pod，造成副本数持续为 0。在故障域迁移场景中，建议使用 matchExpressions 提供更灵活的匹配逻辑。
2.3 滚动更新机制详解
滚动更新是 Deployment 默认的更新策略。它通过控制新旧 ReplicaSet 的副本数变化，实现 Pod 的平滑替换。更新过程由两个关键参数驱动：maxSurge 和 maxUnavailable。
2.3.1 滚动更新参数
| 参数 | 默认值 | 含义 | 故障域影响 |
|---|---|---|---|
maxSurge |
25% | 更新期间允许超出期望副本数的最大 Pod 数量 | 超出部分可能突破节点资源限制，引发调度失败 |
maxUnavailable |
25% | 更新期间允许不可用 Pod 的最大数量 | 设置过小会导致更新缓慢，设置过大会降低故障域容错能力 |
2.3.2 滚动更新流程
以下是一个副本数为 4、maxSurge=1、maxUnavailable=1 的典型滚动更新步骤：
- 创建新 ReplicaSet：Deployment 创建新 RS (v2)，初始副本数为 0。
- 扩容新 RS：新 RS 创建 1 个新 Pod（受 maxSurge 限制），等待 Pod 进入 Ready 状态。
- 缩容旧 RS：新 Pod Ready 后，旧 RS (v1) 删除 1 个旧 Pod（受 maxUnavailable 限制）。
- 循环迭代：重复步骤 2-3，直到新 RS 达到期望副本数，旧 RS 副本数归零。
- 清理：旧 RS 保留在系统中（用于回滚），但副本数置为 0。
2.4 更新策略对比
| 策略 | 行为 | 适用场景 | 故障域风险 |
|---|---|---|---|
| RollingUpdate | 逐步替换 Pod，新旧版本共存 | 生产环境默认策略，追求零停机 | 新旧 Pod 可能同时分布在同一个故障域内，导致故障域内版本不一致 |
| Recreate | 先删除所有旧 Pod，再创建新 Pod | 开发环境、有状态应用、数据库迁移 | 更新期间服务完全不可用，故障域隔离失效 |
2.5 回滚机制
Deployment 默认保留最近 10 个 ReplicaSet 版本（通过 spec.revisionHistoryLimit 控制）。回滚操作本质上是将 Deployment 的 Pod template 重置为历史版本，触发新一轮滚动更新。
# 查看 Deployment 更新历史
kubectl rollout history deployment/my-app
# 回滚到上一个版本
kubectl rollout undo deployment/my-app
# 回滚到指定版本
kubectl rollout undo deployment/my-app --to-revision=32.6 本节小结
Deployment 的三层架构（Deployment → ReplicaSet → Pod）为故障域隔离提供了天然的抽象边界。滚动更新机制虽然实现了零停机部署，但其默认的“无拓扑感知”行为可能导致 Pod 在故障域内分布不均。理解 ReplicaSet 的选择器机制、滚动更新的参数控制以及回滚的副作用，是后续设计故障域隔离策略的基础。