1. 课程导论：集群升级故障域、etcd 核心地位与多租户迁移恢复演练的必要性
1.1 集群升级故障域：从单点故障到分布式风险
在 Kubernetes 集群的生命周期管理中，升级是最常见也最具风险的操作之一。传统运维视角往往只关注升级流程本身，而忽略了升级过程中可能触发的故障域问题。所谓集群升级故障域，是指在升级操作期间，由于组件版本不兼容、配置漂移、资源耗尽或状态不一致等原因，导致集群部分或全部功能失效的风险区域。
升级故障域的核心特征包括：
- 时间窗口性：故障仅在升级窗口内暴露，升级完成后可能自动恢复，难以事后复现。
- 组件耦合性：升级顺序错误或版本跳跃可能导致控制面组件（如 etcd、kube-apiserver、kube-controller-manager）之间的协议断裂。
- 状态依赖性：有状态组件（尤其是 etcd）在升级期间若遭遇写入压力或网络分区，可能引发数据不一致或领导者选举风暴。
关键认知： 升级故障域不是“升级失败”的同义词，而是“升级期间故障影响范围”的度量。理解故障域，才能设计出有效的迁移与恢复策略。
1.2 etcd 在 Kubernetes 中的核心地位
etcd 是 Kubernetes 控制面的唯一状态存储，所有集群对象（Pod、Service、ConfigMap、Secret、RBAC 规则等）的最终一致性数据均持久化在 etcd 中。其核心地位体现在以下三个层面：
| 层面 | etcd 角色 | 故障影响 |
|---|---|---|
| 数据持久化 | 集群所有资源的权威数据源 | etcd 不可用 → 集群状态丢失，无法调度、无法恢复 |
| 领导者选举 | 提供分布式锁与租约机制 | 领导者选举失败 → 控制面组件脑裂，控制器循环中断 |
| 事件与监控 | 存储集群事件与状态变更历史 | 事件丢失 → 审计与排障能力瘫痪 |
⚠️ 风险提示： 在升级场景中，etcd 的版本必须严格遵循 Kubernetes 版本兼容矩阵。etcd 3.4 与 3.5 之间的数据格式差异、Raft 协议变更，都可能在升级过程中引发不可逆的数据损坏。任何跳过 etcd 版本的升级操作都应视为高危行为。
1.3 多租户迁移恢复演练的必要性
在 etcd 故障场景下，多租户环境面临比单租户集群更复杂的恢复挑战：
- 租户隔离失效：etcd 故障可能导致 Namespace 级别的资源边界模糊，租户 A 的数据可能被租户 B 的控制器误操作。
- 迁移优先级冲突：多个租户同时请求迁移恢复时，缺乏优先级策略会导致资源争抢和恢复延迟。
- 数据一致性校验：恢复后的数据必须逐租户进行一致性校验，否则可能引入静默数据损坏。
进行多租户迁移恢复演练的核心价值在于：
| 演练目标 | 具体收益 |
|---|---|
| 验证恢复流程 | 确保 etcd 快照恢复、数据迁移、租户重映射等步骤可重复执行 |
| 测量 RTO/RPO | 量化多租户场景下的恢复时间目标与数据恢复点目标 |
| 暴露隐性依赖 | 发现跨租户的共享资源（如 CRD、Webhook、准入控制器）在恢复后的状态冲突 |
| 培训运维团队 | 在非生产环境中建立肌肉记忆，降低真实故障时的操作失误率 |
💡 最佳实践： 建议每季度至少执行一次多租户迁移恢复演练，演练范围应覆盖 etcd 完全故障、部分节点故障、数据损坏三种典型场景。演练后必须输出《恢复演练报告》，记录实际 RTO、数据校验结果、流程改进项。