Kubernetes 多集群与容灾设计：从隔离边界到故障切换

当业务规模增长后，团队很容易提出“我们要多集群”。多集群可以提升隔离性、可用性和扩展能力，也会带来配置同步、流量治理、数据一致性、权限管理和排障复杂度。好的多集群设计不是集群数量越多越好，而是每个集群边界都有清晰目的。

多集群通常服务于四类目标：环境隔离、团队隔离、区域容灾、容量扩展。不同目标对应完全不同的架构。

什么时候需要多集群

适合多集群的场景：

• 生产与非生产必须强隔离。
• 不同地域用户需要就近访问。
• 单集群规模接近管理上限。
• 核心业务需要区域级容灾。
• 不同团队需要独立升级节奏。
• 合规要求数据或工作负载隔离。

不适合盲目多集群的场景：

• 团队连单集群监控和发布都不成熟。
• 只是为了“看起来高可用”。
• 数据层没有容灾能力。
• 缺少统一配置和权限管理。

多集群会放大平台能力短板。如果单集群已经混乱，多集群通常只会让混乱翻倍。

集群边界设计

常见边界方式：

• 按环境：dev、staging、prod。
• 按地域：hongkong、singapore、tokyo。
• 按业务域：payment、content、analytics。
• 按租户：大客户独立集群。
• 按风险等级：核心链路与实验业务分离。

边界要结合故障域。一个集群故障时，影响面应该可预期。不要把所有核心服务和所有实验任务混在同一个生产集群里，也不要把强依赖服务拆到网络延迟很高的集群之间。

流量治理

多集群流量入口通常有几种模式：

• DNS 权重切换。
• 全局负载均衡。
• Anycast 或云厂商 Global LB。
• Service Mesh 多集群。
• API Gateway 按区域路由。

DNS 切换简单，但受 TTL 和客户端缓存影响，故障切换不一定即时。全局负载均衡能力更强，但需要额外成本和云平台绑定。Service Mesh 能提供细粒度服务间流量治理，但运维复杂度更高。

对大多数团队，先做好南北向入口的健康检查和区域切换，比一开始上复杂 Mesh 更实际。

数据是容灾核心

多集群容灾最难的不是 Pod 拉起，而是数据。应用可以在另一个集群重新部署，数据库、消息队列、对象存储、缓存状态如何恢复才是关键。

要明确：

• RTO：故障后多久恢复服务。
• RPO：最多允许丢失多久数据。
• 主备还是双活。
• 数据复制延迟。
• 冲突解决策略。
• 故障切换后如何回切。

如果数据层只能单区域运行，那么应用多集群只能解决计算层故障，无法真正解决区域级灾难。

配置同步

多集群最怕配置漂移。建议用 GitOps 管理多集群期望状态，通过目录或分支区分集群差异。

clusters/
  prod-hk/
    apps/
    platform/
  prod-sg/
    apps/
    platform/

共享配置放 base，区域差异放 overlay。Secret 使用外部密钥系统或加密方案，避免复制明文。

平台组件版本也要有矩阵管理。Ingress、CNI、CSI、监控、证书管理器在不同集群版本不一致时，排障难度会显著上升。

服务发现

跨集群服务发现需要谨慎。不要让所有服务默认跨集群互通。跨集群调用会引入延迟、网络抖动、安全边界和故障传播。

推荐原则：

• 用户入口按区域进入本地集群。
• 服务优先访问本地依赖。
• 只有明确需要的服务开放跨集群访问。
• 跨集群调用必须有超时、重试和熔断。
• 关键依赖要有降级策略。

如果没有治理，跨集群调用会让一个区域故障传播到另一个区域。

容灾演练

没有演练的容灾方案不可信。演练场景包括：

• 单个节点池不可用。
• 整个集群 API 不可用。
• Ingress Controller 故障。
• 区域入口流量切走。
• 数据库主区域不可用。
• GitOps 控制器误同步。
• Secret 或证书异常。

演练要记录实际 RTO、RPO、人工步骤、失败点和改进项。不要只在文档里写“可切换”，要真正切一次。

监控视图

多集群需要全局视图和局部视图。全局视图看区域健康、入口流量、SLO、错误预算、容量水位。局部视图看单集群组件、节点、工作负载、网络和存储。

告警也要避免重复轰炸。一个区域入口故障可能触发上百条服务告警，需要通过告警聚合和抑制，让值班人员先看到根因级信号。

权限与审计

多集群权限要统一身份源，但授权范围应最小化。平台管理员可以跨集群操作，应用团队通常只应访问自己的 namespace 或项目。

审计日志需要集中保存。事故发生时，团队必须能跨集群追踪变更：谁修改了路由，谁调整了副本，谁更新了 Secret，哪个 Git commit 触发了同步。

总结

多集群不是 Kubernetes 的高级装饰，而是更复杂的生产系统。它能带来隔离、扩展和容灾能力，也会要求更强的配置管理、流量治理、数据复制、监控和演练能力。判断一个多集群方案是否成熟，不看集群数量，而看故障发生时能否清楚切换、数据是否可信、团队是否知道下一步该做什么。