📚 课程目录第1章多集群架构概述

自动化回滚策略在K8s多集群环境配置 - 第1节

1.1 为什么需要多集群

单一 Kubernetes 集群在规模、可用性、安全隔离和地理分布上存在天然上限。随着业务增长，多集群架构从“可选”变为“必需”。以下是驱动多集群部署的核心因素：

实践建议： 在规划多集群之前，先评估业务是否真正需要。如果团队规模小于 20 人、集群节点少于 50 个，单集群配合命名空间隔离通常是更优选择。多集群引入的运维复杂度需要匹配相应的自动化能力。

业界主流的多集群拓扑有两种：Hub-Spoke（中心辐射型） 和 Federation（联邦型）。两种模式在控制流、数据同步和故障隔离上存在本质差异。

由一个中心集群（Hub）统一管理多个工作集群（Spoke）。Hub 集群运行控制面组件（如 karmada-apiserver、cluster-manager），Spoke 集群只运行工作负载。控制流从 Hub 下发，数据面流量在 Spoke 之间或 Spoke 与外部之间直接通信。

  适用场景： 跨区域容灾、混合云统一管理、多环境（dev/staging/prod）隔离。Hub-Spoke 是目前社区最成熟的多集群模式，Karmada、OCM（Open Cluster Management）均采用此架构。

通过联邦控制面（Federation Control Plane）将多个集群抽象为一个逻辑集群。用户向联邦 API 提交资源，联邦控制器负责将资源分发到所有成员集群。与 Hub-Spoke 不同，Federation 更强调“统一视图”和“跨集群同步”。

注意： Federation 架构在回滚场景下存在“同步风暴”风险。当某个成员集群触发回滚时，状态变化会反向同步回控制面，进而触发其他集群的连锁更新。自动化回滚策略必须设计“回滚传播抑制”机制，避免跨集群回滚雪崩。

多集群在带来弹性和容灾能力的同时，也引入了显著的运维复杂性。以下是在自动化回滚场景下必须正视的挑战：

配置一致性管理： 不同集群的 K8s 版本、CNI 插件、存储类、Ingress 控制器可能存在差异。同一份 YAML 在集群 A 正常，在集群 B 可能因缺少 CRD 而失败。回滚时需感知集群差异。
状态同步延迟： Hub-Spoke 模式下，Spoke 集群的状态上报存在秒级到分钟级延迟。回滚指令下发后，无法立即确认所有集群是否已生效。
回滚范围控制： 一次部署可能涉及 10+ 集群。回滚时是全部回滚，还是仅回滚失败的集群？部分回滚可能导致集群间版本不一致，引发流量调度异常。
跨集群依赖： 微服务 A 在集群 1，微服务 B 在集群 2，且 A 调用 B。回滚 A 时，B 的 API 版本可能不兼容，导致调用链断裂。
审计与可观测性： 多集群环境下，回滚事件分散在多个集群的日志和事件流中。需要统一的审计追踪，否则故障定位如同大海捞针。
权限与安全： 回滚操作通常需要高权限（如 cluster-admin）。多集群环境下，密钥和 ServiceAccount 的跨集群分发增加了泄露风险。