1. 课程导论：多租户集群架构概述、etcd在集群中的核心地位、故障域概念与租户隔离的必要性
1.1 多租户集群架构概述
在云原生时代，多租户架构已成为企业级 Kubernetes 集群的标准部署模式。其核心目标是在共享基础设施上，为多个独立业务单元或客户（租户）提供逻辑隔离的运行环境，同时兼顾资源利用率与运维效率。
典型的多租户集群架构包含以下关键层次：
| 层次 | 组件/对象 | 隔离粒度 |
|---|---|---|
| 控制面隔离 | API Server、Scheduler、Controller Manager | RBAC、Admission Webhook、Namespace |
| 数据面隔离 | etcd 集群 | 租户前缀、存储配额、请求优先级 |
| 工作负载隔离 | Pod、Service、NetworkPolicy | NodeSelector、Taint/Toleration、CNI 策略 |
| 资源隔离 | ResourceQuota、LimitRange | CPU/内存/存储/对象数量 |
关键认知： 多租户并非简单的 Namespace 划分，而是从控制面到数据面、从网络到存储的全栈隔离设计。etcd 作为集群的唯一状态存储，其故障域直接决定了所有租户的可用性边界。
1.2 etcd 在集群中的核心地位
etcd 是 Kubernetes 集群的大脑与记忆体，所有集群状态——包括 Pod 调度、Service 发现、ConfigMap、Secret、RBAC 策略——均以键值对形式持久化存储在 etcd 中。其核心作用可归纳为：
- 强一致性存储： 基于 Raft 共识算法，保证集群状态在多个副本间严格一致。
- 集群状态中枢： API Server 的所有读写操作最终都转化为对 etcd 的请求。
- 租户元数据载体： 每个租户的 Namespace、资源配额、网络策略等元数据均存储在 etcd 中。
- 故障恢复基石： 集群升级、节点故障、数据恢复均依赖 etcd 的快照与数据完整性。
以下 SVG 图展示了 etcd 在 Kubernetes 多租户集群中的核心位置与数据流向：
实践要点： etcd 的读写延迟直接影响 API Server 的响应时间，进而影响所有租户的调度与编排效率。在集群升级场景中，etcd 的稳定性是租户无感升级的前提条件。
1.3 故障域概念与租户隔离的必要性
故障域（Failure Domain） 是指系统中一组共享同一故障风险的组件集合。在 Kubernetes 集群中，故障域可以按物理（机架、数据中心、可用区）或逻辑（etcd 成员、控制面组件、网络路径）维度划分。
当 etcd 发生故障时，其影响范围取决于故障域的设计：
- 单点故障域： 所有租户共享同一个 etcd 集群，一次 etcd 宕机或数据损坏将导致全集群不可用，所有租户业务中断。
- 隔离故障域： 通过 etcd 前缀隔离、租户专属 etcd 集群或代理层分流，将故障影响限制在单个或少数租户范围内。
以下 SVG 图对比了无隔离与有隔离两种故障域模型：
核心结论： 在集群升级过程中，etcd 的故障域设计直接决定了爆炸半径。未做租户隔离的集群，一次 etcd 升级失败可能导致全集群回滚；而具备隔离能力的集群，可以将故障限制在单个租户域内，实现灰度升级与故障隔离。
1.4 本课程的核心目标
通过本课程，你将掌握以下关键能力：
- 多租户 etcd 架构设计： 理解如何通过 etcd 前缀、租户专属集群、代理层等模式实现租户级故障域隔离。
- 集群升级中的 etcd 故障模拟： 使用混沌工程工具（如 Chaos Mesh、Litmus）模拟 etcd 节点宕机、网络分区、数据损坏等故障场景。
- 租户隔离验证方法： 设计测试用例，验证故障发生时非故障租户的业务连续性。
- 生产级最佳实践： 从 etcd 备份恢复、Raft 成员变更、升级策略等维度，构建可落地的多租户故障域方案。