2. Kubernetes Deployment 基础回顾：ReplicaSet、滚动更新策略、Pod 生命周期
在深入多租户故障域之前，必须重新夯实 Deployment 的核心机制。Deployment 并非直接管理 Pod，而是通过 ReplicaSet 实现声明式副本控制，再通过 滚动更新策略 完成版本切换。Pod 自身的生命周期状态变化，则是故障检测与恢复的底层信号。
2.1 ReplicaSet：副本管理的基石
ReplicaSet（RS）是 Kubernetes 中保证指定数量的 Pod 副本始终运行的控制器。Deployment 每次更新都会创建一个新的 ReplicaSet，并逐步调整新旧 RS 的副本数，从而实现零停机发布。
| 组件 | 职责 | 与 Deployment 的关系 |
|---|---|---|
| ReplicaSet | 通过 Label Selector 匹配 Pod，确保期望副本数 | Deployment 控制 RS 的创建、伸缩与销毁 |
| Pod Template | 定义 Pod 的容器、卷、资源等规格 | 每个 RS 拥有独立的 Pod Template 哈希 |
| Revision | 记录 Deployment 的变更历史 | 每个 RS 对应一个 revision，支持回滚 |
关键认知： 多租户场景下，每个租户的 Pod 通常由独立的 Deployment 管理。当滚动更新中断时，ReplicaSet 的副本数偏差是判断“部分租户可用”的核心指标。
2.2 滚动更新策略：maxSurge 与 maxUnavailable
滚动更新策略通过两个关键参数控制更新速率与可用性边界：
- maxSurge：更新期间允许超出期望副本数的最大 Pod 数量（可以是值或百分比）。
- maxUnavailable：更新期间允许不可用 Pod 的最大数量（值或百分比）。
默认值为 maxSurge=25% 和 maxUnavailable=25%，意味着更新过程中始终至少有 75% 的 Pod 可用。
apiVersion: apps/v1
kind: Deployment
metadata:
name: tenant-app
spec:
replicas: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 3 # 允许最多 3 个额外 Pod
maxUnavailable: 2 # 允许最多 2 个 Pod 不可用
template:
spec:
containers:
- name: app
image: app:v2
实践建议： 对于多租户场景，建议将
maxUnavailable 设置为 0，确保更新期间不会主动杀死旧 Pod，直到新 Pod 通过 Readiness Probe。这能最大限度降低租户中断风险。
2.3 Pod 生命周期：从 Pending 到 Running 再到 Terminating
Pod 的生命周期状态是滚动更新是否健康、租户是否可用的直接反映。以下是 Pod 的核心阶段及其在多租户场景下的含义：
| 阶段 | 状态描述 | 租户影响 |
|---|---|---|
| Pending | Pod 已被 API Server 接受，但尚未调度到节点或镜像拉取中 | 租户请求可能超时，需等待调度完成 |
| Running | Pod 已绑定到节点，所有容器已启动且至少有一个容器处于运行状态 | 租户可正常访问（需通过 Readiness Probe 确认） |
| Succeeded | Pod 中所有容器成功终止（通常用于 Job） | 不适用于长期运行的服务 |
| Failed | Pod 中所有容器终止，且至少一个容器以非零状态退出 | 租户服务中断，需触发自愈或回滚 |
| Unknown | API Server 无法获取 Pod 状态（如节点失联） | 租户状态不确定，需人工介入 |
故障域关联： 滚动更新期间，如果新 Pod 长时间处于 Pending（资源不足）或 CrashLoopBackOff（应用启动失败），会导致
maxUnavailable 阈值被突破，进而影响存量租户的可用性。
2.4 滚动更新与 Pod 生命周期的联动
滚动更新本质上是一个“创建新 Pod → 等待就绪 → 销毁旧 Pod”的循环。每个循环步骤都依赖 Pod 生命周期状态：
- 扩容新 RS：创建新 Pod，状态从 Pending 变为 Running。
- 等待就绪：Running 状态 + Readiness Probe 成功 → Pod 进入 Service 端点。
- 缩容旧 RS：旧 Pod 进入 Terminating 状态，优雅关闭（PreStop Hook + terminationGracePeriodSeconds）。
- 循环：重复步骤 1-3，直到所有旧 Pod 被替换。
多租户启示： 如果某个租户的 Pod 在步骤 2 中无法通过 Readiness Probe（例如新版本连接数据库失败），滚动更新会阻塞，导致该租户的旧 Pod 不会被销毁，但新 Pod 也无法提供服务。此时需要人工干预或自动回滚策略。