1. 课程导论:多租户架构概述、故障域隔离的重要性、etcd在集群中的核心角色
1.1 多租户架构概述
多租户架构是云原生平台的核心设计模式之一,它允许一个共享的 Kubernetes 集群安全地服务于多个独立的“租户”。每个租户可以是一个团队、一个项目、一个业务线或一个外部客户。其核心目标是实现资源隔离与成本共享的平衡。
关键设计原则: 租户之间必须实现计算、网络、存储以及控制平面的逻辑或物理隔离,确保一个租户的故障或恶意行为不会影响其他租户。
在 Kubernetes 中,多租户的实现通常分为三个层级:
| 层级 | 隔离粒度 | 典型实现 | 适用场景 |
|---|---|---|---|
| 软多租户 | 命名空间 (Namespace) | RBAC + NetworkPolicy + ResourceQuota | 内部团队、开发/测试环境 |
| 硬多租户 | 虚拟集群 (vCluster) / 节点池 | 虚拟集群、节点亲和性、Pod Security Admission | 高安全要求、合规性场景 |
| 物理多租户 | 独立集群 | 每个租户一个独立 Kubernetes 集群 | 金融、医疗等强监管行业 |
1.2 故障域隔离的重要性
故障域隔离是保障多租户系统韧性的核心手段。在集群升级、网络分区或硬件故障时,如果没有合理的故障域设计,一个租户的异常行为可能迅速扩散为全局性灾难。
常见风险场景: 集群升级过程中,如果 etcd 集群因升级操作出现脑裂或写入超时,所有依赖 API Server 的租户(包括正在运行的工作负载)都将失去控制面响应,导致服务中断。
故障域隔离的设计目标包括:
- 限制爆炸半径: 确保单个租户的故障(如资源耗尽、配置错误)不会影响控制面或其他租户。
- 保障控制面可用性: etcd 作为控制面的状态存储,必须通过跨可用区部署、Raft 协议和备份策略实现高可用。
- 支持灰度恢复: 在故障发生后,能够按租户粒度进行回滚或恢复,而不是全集群重建。
1.3 etcd 在集群中的核心角色
etcd 是 Kubernetes 控制面的基石,它作为分布式键值存储,负责保存集群的所有状态数据。理解 etcd 的架构和故障模式,是进行多租户灾难恢复的前提。
核心事实: Kubernetes API Server 是无状态的,所有持久化状态(Pod、Service、ConfigMap、Secret 等)都存储在 etcd 中。etcd 不可用 = 集群控制面瘫痪。
etcd 在集群中的关键职责:
- 状态持久化: 存储所有 Kubernetes 资源对象的当前状态和期望状态。
- 分布式共识: 通过 Raft 协议保证数据在多个 etcd 节点间的一致性。
- 监听与通知: 支持 Watch 机制,API Server 通过 etcd 的 Watch 接口实时感知资源变化。
- 租约管理: 管理分布式锁和节点心跳(Lease 对象)。
| etcd 组件 | 功能 | 故障影响 |
|---|---|---|
| Raft 层 | Leader 选举、日志复制、一致性保证 | Leader 故障 → 重新选举(秒级);多数节点故障 → 集群只读或不可用 |
| 存储引擎 (BoltDB) | 持久化键值数据到磁盘 | 磁盘损坏 → 数据丢失;性能瓶颈 → 写入延迟升高 |
| Watch 服务 | 向 API Server 推送资源变更事件 | Watch 积压 → 控制器同步延迟;连接断开 → 状态不一致 |
| 租约模块 | 管理 TTL 和分布式锁 | 租约过期 → 节点被标记为 NotReady;锁丢失 → 控制器重复调度 |
1.4 课程目标与演练范围
本课程将聚焦于一个高风险的现实场景:在集群升级过程中,etcd 集群发生故障,导致多租户环境下的控制面不可用。学员将通过本课程掌握以下能力:
- 识别 etcd 故障的早期信号(如 Leader 切换频繁、写入延迟飙升)。
- 执行 etcd 备份恢复操作,并验证数据一致性。
- 按租户粒度进行故障域隔离恢复,最小化对其他租户的影响。
- 设计升级流程中的熔断与回滚机制。
演练前提: 学员需具备基本的 Kubernetes 集群管理经验,了解 etcd 的 Raft 协议原理,并拥有集群管理员权限。本课程提供的所有脚本和配置均基于 Kubernetes v1.28+ 和 etcd v3.5+。