2、多集群管理基础：Kubernetes多集群管理的基本概念、常见模式以及多集群etcd的部署拓扑
2.1 为什么需要多集群管理
单一Kubernetes集群在规模、故障隔离、地域分布和合规性方面存在天然上限。当企业业务跨越多个数据中心、公有云区域或混合云环境时，多集群管理成为基础设施的必然选择。核心驱动力包括：
- 故障域隔离：单个集群的控制面故障不会影响其他集群的业务连续性。
- 地域亲和与延迟优化：将工作负载部署到离用户最近的集群，降低网络延迟。
- 合规与数据主权：不同国家/地区的数据必须存储在本地集群中。
- 资源弹性与成本：跨集群调度工作负载，利用不同云厂商或机房的资源差价。
- 蓝绿部署与容灾：多集群可作为异地灾备或灰度发布的基础单元。
SRE视角： 多集群不是简单复制单集群配置，而是引入控制面联邦、网络互通、etcd数据一致性等新复杂度。etcd作为Kubernetes的存储后端，在多集群场景下的拓扑设计直接影响故障恢复时间（RTO）和数据恢复点（RPO）。
2.2 多集群管理常见模式
业界主流的多集群管理模式分为Hub-Spoke（中心辐射）和Federation（联邦）两大类。下表从控制面耦合度、etcd拓扑影响和运维复杂度三个维度进行对比：
| 对比维度 | Hub-Spoke 模式 | Federation 模式 |
|---|---|---|
| 控制面耦合度 | Hub集群拥有全局控制面，Spoke集群保留本地控制面；Hub故障不影响Spoke已有业务，但影响调度决策。 | 通过联邦控制面（如KubeFed）同步资源；各集群控制面独立，联邦层仅做资源分发。 |
| etcd拓扑影响 | Hub集群的etcd存储全局元数据（集群注册、策略、全局资源）；Spoke集群etcd仅存储本地数据。 | 联邦控制面自身需要etcd存储联邦资源模板和覆盖策略；各成员集群etcd独立运行。 |
| 运维复杂度 | 中等；需要维护Hub集群的高可用etcd，Spoke集群可相对轻量。 | 较高；联邦控制面etcd与成员集群etcd之间无直接数据同步，但资源冲突解决复杂。 |
| 典型场景 | 边缘计算、多云统一管理、集群注册与发现。 | 跨集群服务发现、统一配置管理、灰度发布。 |
2.3 Hub-Spoke 模式详解
Hub-Spoke是目前生产环境中最广泛采用的多集群管理模式。其核心思想是：一个中心集群（Hub）作为管理入口，多个工作集群（Spoke）通过Agent或VPN隧道注册到Hub。Hub集群的etcd存储全局状态，Spoke集群的etcd仅存储本地负载。
关键设计原则：
- Hub集群的etcd必须部署3节点或5节点高可用集群，因为它是全局控制面的单点。
- Spoke集群与Hub之间的网络连接必须稳定，建议使用专用网络或VPN隧道。
- Hub集群不直接运行业务Pod，仅运行管理组件（如Cluster API、Karmada控制面）。
2.4 Federation 模式详解
Federation模式通过一个联邦控制面（如KubeFed或Karmada）将多个Kubernetes集群抽象为一个逻辑集群。联邦控制面拥有独立的etcd存储，用于保存联邦资源模板（FederatedResourceTemplate）、覆盖策略（Overrides）和调度策略。成员集群的etcd完全独立，联邦层仅负责将资源推送到目标集群。
etcd运维警告： 联邦控制面的etcd虽然数据量通常小于成员集群，但其存储的是全局资源模板和策略。一旦联邦etcd损坏，所有集群的资源分发将中断。建议联邦etcd至少部署3节点，并开启定期快照备份。
2.5 多集群etcd部署拓扑
在多集群管理场景下，etcd的部署拓扑需要根据管理模式进行差异化设计。下表总结了三种典型拓扑及其适用场景：
| 拓扑类型 | etcd集群数量 | 数据一致性要求 | 典型场景 | RTO目标 |
|---|---|---|---|---|
| 独立etcd（每个集群独立） | N个（N=集群数） | 无跨集群一致性要求 | Hub-Spoke模式下的Spoke集群 | < 5分钟 |
| 全局etcd（共享） | 1个（多节点高可用） | 强一致性（Raft） | Hub-Spoke模式下的Hub集群 | < 1分钟 |
| 联邦etcd（独立） | 1个（多节点高可用） | 最终一致性（资源分发） | Federation模式下的联邦控制面 | < 2分钟 |
2.6 多集群etcd压测关注点
在后续章节的压测沙盘实验中，我们将重点验证以下多集群etcd性能指标：
- Hub集群etcd的写入吞吐：当大量Spoke集群同时注册或更新状态时，Hub集群etcd的QPS和延迟表现。
- 联邦etcd的资源模板同步延迟：从联邦控制面写入资源模板到成员集群实际生效的时间差。
- 跨集群网络延迟对etcd健康检查的影响：Cilium网络故障（如丢包、延迟抖动）如何影响etcd节点间的Raft心跳。
- etcd快照恢复在多集群场景下的数据一致性：当某个Spoke集群etcd损坏，从备份恢复后如何与Hub集群重新同步。
压测沙盘实验预告： 在第5章中，我们将搭建一个包含1个Hub集群（3节点etcd）和3个Spoke集群（各3节点etcd）的压测环境，使用Cilium模拟网络故障，观察etcd集群的故障转移和数据一致性表现。