1. 多集群架构概述

1.1 为什么需要多集群

单集群在规模、故障域、合规与业务隔离方面存在天然上限。当集群节点数超过 5,000、Pod 数超过 150,000 时，etcd 性能与 API Server 压力会显著上升。更关键的是，单集群是一个故障域——控制面故障、升级失误或恶意攻击都可能导致全局不可用。多集群架构通过将工作负载分散到多个独立集群，从根本上解决了这些问题。

1.2 典型应用场景

场景一：灾备（Disaster Recovery）

主集群部署在生产地域，备集群部署在异地。通过 Velero 或 KubeFed 定期同步资源与数据。当主集群整体故障时，DNS 或全局负载均衡器将流量切至备集群。RTO（恢复时间目标）可控制在分钟级，RPO（恢复点目标）取决于数据同步频率。

场景二：地域亲和（Geo-Affinity）

用户请求延迟敏感的业务需要就近接入。在多个地理区域部署集群，配合 Global Load Balancer 或 Service Mesh 多集群路由，将流量调度到离用户最近的集群。典型场景包括：游戏服、直播推流、边缘计算。

场景三：隔离性（Isolation）

• 环境隔离： 开发、测试、预发、生产各占独立集群，避免资源争抢与配置污染。
• 租户隔离： 金融、医疗等强合规行业，不同客户或业务线使用独立集群，满足审计要求。
• 工作负载隔离： 在线业务与离线批处理分离，避免离线任务抢占 CPU 导致在线抖动。

1.3 多集群带来的挑战

多集群在解决单集群问题的同时，也引入了新的复杂度。以下是在规划多集群架构时必须面对的六大挑战：

1. 控制面分裂： 每个集群有独立的 API Server 和 etcd，运维人员需要在多个控制面之间切换，操作一致性难以保证。
2. 网络互通复杂： 跨集群 Pod/Service 通信需要 CNI 插件支持（如 Cilium Cluster Mesh、Submariner），延迟和带宽开销不可忽视。
3. 资源调度碎片化： 全局资源视图缺失，容易导致部分集群资源利用率过高而其他集群闲置，整体利用率反而下降。
4. 配置与策略同步： RBAC、NetworkPolicy、LimitRange 等需要在集群间保持同步，手动维护极易出错。
5. 可观测性割裂： 日志、指标、追踪分散在多个集群，需要统一的可观测性平台（如 Thanos、Grafana Mimir、Loki）进行聚合。
6. CI/CD 适配： 部署流水线需要感知多集群拓扑，支持灰度发布、金丝雀部署等策略。

1.4 挑战应对思路概览

本课程后续章节将逐一深入这些挑战的解决方案。这里先给出一个宏观应对框架：