Kubernetes 多集群与集群舰队管理实战

当单个 Kubernetes 集群已经无法同时满足地域隔离、故障域隔离、合规边界和团队自治要求时，多集群才真正有价值。多集群不是“多装几套 Kubernetes”，而是把集群本身当作一种可持续交付、可统一治理、可独立失效的基础设施产品。

本文从生产落地角度说明如何建立集群清单、统一交付应用与策略、设计跨集群流量、控制配置漂移，并给出升级、灾备和故障处置方法。重点不是某一个平台，而是一套可以迁移到不同产品上的舰队管理思路。

一、先判断是否真的需要多集群

适合采用多集群的典型情况包括：

不同城市、可用区或数据中心需要独立故障域；
生产、测试或不同安全等级必须进行强隔离；
多个业务团队需要独立的升级窗口和资源配额；
单集群规模已经逼近控制面、网络或运维团队的管理边界；
业务要求异地容灾、就近接入或数据驻留；
边缘节点多且网络不稳定，需要区域自治。

下面的问题不应仅靠增加集群掩盖：

单集群内没有资源配额，团队互相争抢资源；
监控、备份和升级流程尚未标准化；
应用依赖本地磁盘、固定 IP 或人工发布；
集群版本失控，插件和证书没有生命周期管理；
没有定义恢复时间目标 RTO 和恢复点目标 RPO。

多集群会把已有的运维问题成倍放大。正确顺序通常是先把一套集群做成可复制的标准产品，再扩展为舰队。

二、常见管理模型

1. 完全独立

每个集群拥有独立的管理员、发布链路和监控体系。隔离性最好，但一致性差，适用于监管边界明确或不同组织完全自治的场景。

2. 中央管理、分散运行

管理集群维护集群注册、策略、应用模板和可观测性入口，工作负载仍在各成员集群独立运行。管理面故障时，成员集群应继续承载业务。

3. Hub-Spoke

中心集群作为 Hub，成员集群作为 Spoke。Hub 负责分发和汇总，Spoke 只保留必要代理。设计时必须避免 Hub 成为所有运行流量的必经点。

4. GitOps 舰队

Git 保存期望状态，控制器根据目录、标签或集群清单把应用分发到目标集群。它适合审计和回滚，也更容易控制配置漂移。

5. 调度型联邦

使用 Karmada 等平台把策略、资源和故障迁移抽象到多个集群之上。能力更强，但平台本身也需要高可用、升级和灾备，不应在缺少明确需求时过早引入。

常见组合是：Cluster API 管理集群生命周期，Argo CD ApplicationSet 管理应用交付，策略引擎管理安全基线，可观测平台汇总跨集群指标。

三、建立集群资产清单

每个集群至少应记录：

字段	示例	用途
集群标识	cn-sh-prod-01	全局唯一，不随显示名变化
环境	prod / staging	决定策略和发布审批
地域与故障域	上海 / AZ1	流量和容灾决策
Kubernetes 版本	1.xx	升级与兼容性判断
CNI/CSI/Ingress	Cilium / Rook / Gateway	插件生命周期
Pod/Service CIDR	10.20.0.0/16	冲突检测
数据等级	公开 / 内部 / 敏感	合规和跨域限制
责任团队	platform-a	事件升级
维护窗口	周三 01:00	变更排期
备份状态	最近成功时间	恢复准备度
生命周期	建设中 / 运行 / 退役	防止遗留集群

建议为集群增加稳定标签：

metadata:
  labels:
    fleet.example.com/environment: production
    fleet.example.com/region: cn-shanghai
    fleet.example.com/tier: critical
    fleet.example.com/compliance: internal
    fleet.example.com/owner: platform-team

标签值应有受控字典和变更审计。不要把经常变化的人员姓名写入标签，也不要依赖自由文本决定生产发布。

四、用 Cluster API 管理集群生命周期

Cluster API 把集群、控制面和节点池表达为 Kubernetes API 对象。核心概念包括：

Management Cluster：保存集群声明并运行控制器；
Cluster：成员集群的总体声明；
Infrastructure Provider：云平台、虚拟化或裸金属资源；
Control Plane Provider：控制面生命周期；
MachineDeployment：可滚动更新的工作节点组；
Bootstrap Provider：节点初始化方式。

推荐流程：

维护经过验证的集群版本矩阵；
把网络、操作系统镜像、节点规格做成少量标准套餐；
新集群先进入预生产舰队，通过基线检查后再注册生产；
扩缩容、升级和退役均通过声明式变更完成；
管理集群的 etcd、凭据和 Provider 版本单独备份。

管理集群失效不应直接导致成员业务停止，但会影响扩容、升级和修复，因此也必须有明确 RTO 和恢复演练。

五、用 GitOps 分发应用

仓库可按平台基线、环境和集群覆盖项分层：

fleet-config/
├─ platform/
│  ├─ ingress/
│  ├─ observability/
│  └─ policy/
├─ environments/
│  ├─ production/
│  └─ staging/
├─ clusters/
│  ├─ cn-sh-prod-01/
│  └─ cn-bj-prod-01/
└─ applications/
   ├─ order-api/
   └─ portal/

ApplicationSet 可以按集群标签生成应用。例如仅向生产集群分发：

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: platform-production
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            fleet.example.com/environment: production
  template:
    metadata:
      name: '{{name}}-platform'
    spec:
      project: platform
      source:
        repoURL: https://git.example.com/platform/fleet-config.git
        targetRevision: main
        path: platform
      destination:
        server: '{{server}}'
        namespace: platform-system
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

生产使用时还应增加：

Project 白名单限制仓库、目标集群和命名空间；
对自动删除设置资源保护和人工审批边界；
密钥通过 External Secrets、Vault 等系统注入，不进入 Git；
对大规模同步设置批次和并发上限；
为关键资源配置同步窗口；
紧急人工修改记录为事件，并尽快回写期望状态。

六、身份与信任边界

最危险的设计是把一个长期有效、拥有所有集群最高权限的 kubeconfig 放在管理平台上。更稳妥的做法是：

每个成员集群使用独立身份；
只授予注册、读取或部署所需最小权限；
优先使用短期令牌、OIDC 和工作负载身份；
管理操作与应用发布使用不同账户；
审计日志能够区分用户、流水线和控制器；
凭据轮换不依赖重建整个集群；
管理平台泄露时，可以逐集群吊销信任。

跨集群证书、服务网格根证书和镜像仓库凭据必须纳入统一生命周期管理。证书过期往往比节点故障更容易造成全舰队同时中断。

七、跨集群网络规划

1. 避免地址重叠

规划时至少检查 Pod CIDR、Service CIDR、节点网段、办公网、管理网、存储网，以及 VPN、专线和合作方地址。

如果未来需要直接跨集群路由，Pod CIDR 重叠会显著增加 NAT、排障和可观测性复杂度。即使当前没有互联，也应在 IPAM 中预留全局不重叠地址池。

2. 不把互通误认为高可用

跨集群网络连通只解决报文可达，还需考虑：

服务发现和健康状态传播；
网络时延、抖动、丢包和 MTU；
双向身份认证；
故障时流量撤回速度；
数据库写入一致性；
出站访问和审计边界。

3. 服务发现

常见方式包括全局 DNS、全局负载均衡、网关转发和服务网格多集群。对公网应用，通常由全局入口根据地域和健康状态分配到各集群；对内部服务，优先维持集群内调用，只有明确需要时才跨集群访问。

八、数据层决定真正的容灾能力

无状态应用可以在另一个集群快速拉起，但状态数据未必可用。多集群方案必须回答：

数据是单主、多主还是只读副本？
RPO 是零、分钟级还是小时级？
网络分区时谁可以写入？
切换后如何防止旧主继续写入？
对象存储、消息队列和缓存是否具备异地能力？
恢复时如何验证数据完整性和业务语义？

不要让调度平台自动迁移一个不具备多地域一致性的数据库。恢复编排应把数据库、消息队列、密钥、配置和流量入口作为一个整体。

九、跨集群策略与配置漂移

常见基线包括命名空间、资源配额、Pod Security、镜像来源、NetworkPolicy、审计、日志、指标、Ingress/Gateway、DNS、证书和备份代理。

应把偏差分成三类：

允许差异：地域地址、存储类型、节点规格；
临时偏差：故障处置中的人工修改，应设置过期时间；
违规漂移：关闭审计、放开高危权限等，必须告警或阻断。

不要简单地把所有差异自动覆盖。对生产故障现场，强制回滚人工修复可能扩大事故，应提供暂停同步、记录原因和恢复托管的流程。

十、可观测性与舰队 SLO

集群健康

API Server 错误率与延迟；
etcd 空间、延迟、选主和碎片率；
节点 Ready、磁盘、网络和证书状态；
DNS、CNI、CSI、Ingress/Gateway 健康；
待调度 Pod 和资源碎片。

管理面健康

集群注册和心跳延迟；
GitOps 同步成功率和排队时间；
策略分发失败数量；
凭据、证书到期时间；
管理控制器队列深度和错误率。

业务健康

不要只看各集群 Pod 是否 Running，应使用统一业务 SLI，例如请求成功率、端到端延迟、交易完成率和数据新鲜度。

舰队层面可定义关键集群可管理率、配置同步及时率、版本合规率、备份成功率、恢复演练通过率和严重偏差修复时间。

十一、分批升级与版本治理

升级顺序可设计为实验集群、内部开发集群、预生产集群、一个低风险生产集群，再按地域或业务批次扩大，最后升级核心集群。

每一批都应设置停止条件：

API 错误率超过阈值；
CNI、CSI 或 Ingress 出现兼容问题；
节点替换时间显著超出基线；
关键业务 SLO 下降；
新版本出现不可回滚的数据变更。

升级前确认 Kubernetes 版本跨度、废弃 API、Webhook、Operator、容器运行时、内核、CNI 和 CSI 的兼容矩阵。不要让所有集群在同一窗口升级。

十二、容灾切换演练

一次完整演练应包含：

宣布某个地域或集群不可用；
冻结自动发布，防止状态继续变化；
确认数据副本和恢复点；
在备用集群扩容应用；
切换密钥、依赖和消息消费；
调整 DNS 或全局负载均衡；
验证核心交易，而不仅是 HTTP 200；
观察错误率、延迟和积压；
决定是否回切，避免来回抖动；
记录实际 RTO、RPO 和人工步骤。

DNS 切换前要验证 TTL、递归缓存和客户端长连接。切换后仍需保留旧集群流量观测，以发现未迁移客户端。

十三、常见故障处置

管理集群不可用

确认成员业务是否独立运行；冻结危险变更；恢复管理集群 etcd、Provider 和密钥；避免同时新建第二套管理面接管相同资源。

成员集群失联

先区分 API 不可达、代理异常、凭据过期还是地域故障。不要因短暂网络抖动自动删除成员对象或把全部业务迁走。

GitOps 误删资源

立即暂停同步与自动删除；确认影响范围；从 Git 历史和备份恢复；对数据库、PVC 和证书配置额外删除保护。

全舰队证书接近过期

统计使用范围和依赖顺序，分批轮换根证书、中间证书和工作负载证书，保留双信任窗口，并监控握手错误。

跨集群网络分区

阻止双主写入，保持每个地域最小自治能力；确认全局入口撤回异常站点；恢复后先校验数据再回切。

十四、退役集群流程

停止新应用调度和新租户接入；
迁移业务、数据、密钥和外部依赖；
验证 DNS、监控和备份不再引用旧集群；
导出审计记录和必要配置；
撤销云凭据、证书和集群身份；
清理负载均衡、磁盘、快照和公网地址；
从 GitOps、CMDB、监控和告警中注销；
保留退役审批与数据销毁证据。

十五、生产检查清单

架构

[ ] 每个集群的业务边界和故障域明确；
[ ] 管理面故障不会直接中断成员业务；
[ ] 地址池无冲突，跨集群通信边界明确；
[ ] 状态数据有独立的复制与恢复设计。

安全

[ ] 没有共享的长期全局管理员 kubeconfig；
[ ] 所有控制器使用最小权限和可轮换身份；
[ ] 关键证书有到期告警和轮换演练；
[ ] 集群注册、发布和策略变更可审计。

交付与运维

[ ] 集群和插件有支持矩阵；
[ ] 应用按标签、环境和批次分发；
[ ] 自动同步、删除和人工接管边界清晰；
[ ] 有集群、管理面和业务三层 SLO；
[ ] 管理集群及 Git 仓库可恢复；
[ ] 升级使用金丝雀和停止条件；
[ ] 故障切换与集群退役均有演练记录。

参考资料

多集群的目标不是在一个控制台看到更多集群，而是让每个集群都能按照同一套标准被创建、交付、观测、升级、恢复和退役。只有把这些生命周期环节真正自动化，舰队规模扩大后才不会依赖少数人的经验维持。

Kubernetes多集群与集群舰队管理实战