multi-cluster-management

多集群注册、流量与配置分发

补充说明

多集群不是默认选择。只有在合规数据驻留、跨区高可用、强租户隔离或单集群规模上限时才引入。每多一个集群，就多一套升级、证书、监控、配额和故障域。

常见模式：GitOps 每集群一份配置、集群网格做跨集群服务发现、控制平面管理集群生命周期、虚拟集群做租户隔离。

常用示例

集群登记表（必须进 Git，不能只放在 wiki）：

Argo CD ApplicationSet 按集群分发：

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

Cilium Cluster Mesh 跨集群连通：

cilium clustermesh enable --context prod-sh-1
cilium clustermesh enable --context prod-sh-2
cilium clustermesh connect --context prod-sh-1 --destination-context prod-sh-2

方案选择：

决策规则：

• 单集群能通过多可用区满足 RTO/RPO 时，不引入多集群。
• 跨集群流量必须做故障转移演练，不能只在配置里存在。
• 集群版本最多落后两个 minor；升级按批次进行，先非生产后生产。
• 所有集群必须同一套监控、日志和策略基线，否则不纳入生产。

易错点与排错

• 过早多集群，运维成本指数上升，交付速度反而下降。
• 集群清单靠 wiki，实际状态漂移；用 Git 记录并定期对账。
• 每个集群一套手写配置，版本和策略不一致。
• 全局负载均衡没有健康检查和故障转移验证，切换时才发现不可用。
• 假设网络已通，跨集群 DNS、防火墙和 MTU 未验证。
• 证书和密钥分发不同步，轮换时部分集群失效。
• 监控分散，没有全局视图，故障定位靠逐个集群登录。

读完自测

合上页面，先回答，再展开对照。

1. 什么情况下不应该引入多集群？
2. ApplicationSet 的 clusters generator 解决什么问题？
3. 多集群环境为什么必须做故障转移演练？

相关条目

• clusternet — 多集群管理
• submariner — 跨集群网络
• cilium-clustermesh — Cilium 集群网格
• vcluster — 虚拟集群隔离
• cluster-api — 集群生命周期管理