1. 课程导论：多租户场景下的 Deployment 挑战与故障域概念
在云原生架构中，Kubernetes Deployment 是管理无状态工作负载的核心资源。然而，当多个租户共享同一个集群时，Deployment 的滚动更新行为会引入独特的故障风险。本导论将剖析多租户场景下的核心挑战，并正式引入“故障域”这一关键概念。
1.1 多租户场景的典型特征
多租户集群通常具有以下结构特征，这些特征直接影响了 Deployment 的运维策略：
| 特征维度 | 单租户集群 | 多租户集群 |
|---|---|---|
| 资源隔离 | Namespace 仅用于逻辑分组 | Namespace + ResourceQuota + NetworkPolicy 强隔离 |
| 更新影响面 | 仅影响本团队服务 | 可能波及相邻租户的 Pod 调度与网络 |
| 故障半径 | 可控，通常限于单个应用 | 跨租户扩散，需严格限制爆炸半径 |
| 运维权限 | 集群管理员统一操作 | 租户自运维 + 平台管理员分层管控 |
1.2 滚动更新带来的多租户中断风险
Deployment 默认的 RollingUpdate 策略在单租户环境下表现良好，但在多租户共享节点池、共享 CNI 网络或共享存储后端时，可能引发以下连锁中断：
- 节点资源争抢：租户 A 的滚动更新创建大量新 Pod，挤占节点资源，导致租户 B 的 Pod 被驱逐或无法调度。
- 流量迁移抖动：更新过程中 Service Endpoint 切换延迟，租户 C 的客户端连接出现 502/503 错误。
- 共享组件过载：大量 Pod 同时重建导致 DNS、API Server、etcd 等控制面组件压力激增，影响所有租户。
- 配置漂移：更新过程中 ConfigMap/Secret 版本不一致，导致部分租户 Pod 加载到旧配置。
⚠️ 关键警示： 在多租户集群中，一次看似普通的 Deployment 滚动更新，可能演变为“租户级故障”。故障不会自动隔离在单个 Namespace 内，而是通过共享基础设施层扩散。
1.3 故障域概念引入
“故障域”（Failure Domain）源自分布式系统设计，指系统中一个组件失效时，不会导致其他组件也失效的物理或逻辑边界。在 Kubernetes 多租户场景下，我们将故障域定义为：一个租户的 Deployment 更新操作所能造成负面影响的最大范围。
故障域的核心维度包括：
- 节点故障域：Pod 分布在哪些节点上？是否跨可用区？
- 网络故障域：Service 后端 Pod 变更时，流量中断影响哪些客户端？
- 控制面故障域：更新操作对 API Server、Controller Manager 的负载影响。
- 数据面故障域：共享存储、ConfigMap、Secret 的版本一致性边界。
1.4 故障域与滚动更新的关系矩阵
下表总结了不同故障域维度下，滚动更新可能触发的具体中断模式：
| 故障域维度 | 滚动更新触发条件 | 中断表现 | 受影响租户 |
|---|---|---|---|
| 节点故障域 | maxSurge 过高，新 Pod 抢占节点资源 | Pod 驱逐、调度失败 | 同节点池的所有租户 |
| 网络故障域 | Endpoint 更新延迟，旧 Pod 被立即终止 | 连接中断、请求超时 | 调用方租户 |
| 控制面故障域 | 大规模并发更新，API Server 限流 | 更新卡顿、资源创建失败 | 全集群租户 |
| 数据面故障域 | ConfigMap/Secret 版本滚动不一致 | 配置错乱、数据不一致 | 共享配置的租户组 |
1.5 课程核心目标
通过本课程，你将掌握以下能力：
- 识别：在多租户集群中快速定位 Deployment 滚动更新的故障域边界。
- 预防：通过 PodDisruptionBudget、拓扑分布约束、滚动更新参数调优等手段缩小故障域。
- 恢复：当滚动更新导致租户中断时，执行最小化影响的回滚与恢复策略。
- 自动化：构建基于 Operator 的租户级故障域管理机制。
💡 学习建议： 本章节为后续所有内容奠定理论基础。建议你结合自己集群中的实际 Namespace 和 Deployment 配置，尝试画出当前集群的故障域拓扑图。