Kubernetes 多集群管理实战：从 Federation v2 到 Karmada 的企业级容器编排方案

一、为什么需要多集群架构？

随着企业 IT 规模的增长，单一 Kubernetes 集群已无法满足复杂业务需求。多集群架构的驱动力来自多个维度：高可用与灾难恢复要求跨地域/跨云部署、合规要求数据本地存储、团队自治需求独立的扩展与发布节奏、边缘场景需要地理就近调度以及技术异构允许多版本 K8s、多 CNI、多 CSI 的共存演进。

根据 CNCF 2024 年度调查报告，超过 68% 的中大型企业运行着 3 个以上的 Kubernetes 集群，多集群管理已经成为云原生领域不可回避的核心课题。

二、主流多集群管理方案对比

当前社区主流的多集群编排框架各有侧重：

• Karmada（Kubernetes SIG）：对原生 API 完全兼容，声明式分发策略，活跃贡献者社区
• Clusternet（OpenKruise）：轻量级架构，通过代理方式管理子集群
• OCM（Open Cluster Management）：Red Hat 主导，专注治理、策略和可插拔扩展
• Fleet（Rancher）：面向边缘和大规模集群池场景
• Federation v2（已归档）：社区基础设施项目，不再活跃维护

综合考虑社区活跃度、API 兼容性和生产就绪度，Karmada 是目前最推荐的企业级多集群管理方案。

三、Karmada 核心概念与架构

Karmada 采用控制平面与数据平面分离的架构。控制平面（Karmada Control Plane）负责策略分发与状态汇总，各子集群保持完整的自治能力。

# PropagationPolicy 定义多集群分发规则
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: my-service-policy
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: my-service
  placement:
    clusterAffinity:
      clusterNames:
        - cluster-east
        - cluster-west
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        staticWeightList:
          - targetCluster:
              clusterNames: [cluster-east]
            weight: 60
          - targetCluster:
              clusterNames: [cluster-west]
            weight: 40
  failover:
    application:
      decisionConditions:
        - type: Taint
          tolerationSeconds: 300

四、跨集群服务发现与通信

多集群环境下，Service Mesh 是实现跨集群通信的关键基础设施。通过 MCS API（Multi-Cluster Services）或 Service Mesh Federation，可以实现跨集群的命名路由与负载均衡。

# MCS API ServiceExport 导出服务到多集群
apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceExport
metadata:
  name: backend-api
  namespace: production

---
# 在消费端集群创建 ServiceImport
apiVersion: multicluster.x-k8s.io/v1alpha1
kind: ServiceImport
metadata:
  name: backend-api
  namespace: cross-cluster
spec:
  type: ClusterSetIP
  ports:
    - name: https
      protocol: TCP
      port: 443

五、差异化调度与集群覆盖

Karmada 的 OverridePolicy 允许针对不同集群应用差异化配置，这对于处理集群规格差异、地域配置区别非常关键。

apiVersion: policy.karmada.io/v1alpha1
kind: OverridePolicy
metadata:
  name: cluster-east-overrides
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: my-service
  targetCluster:
    clusterNames:
      - cluster-east
  overriders:
    imageOverrrider:
      - component: Repository
        operator: add
        value: myregistry-east.example.com
    cmdOverrider:
      - containerName: main
        operator: add
        value: ["--region=east-1"]
    labelsOverrider:
      - operator: add
        value:
          region: east-1
          zone: east-1a

六、多集群监控与灾难恢复

生产级多集群部署必须建立完善的监控与容灾体系。通过 Thanos 或 VictoriaMetrics 实现跨集群指标聚合，在中心控制平面全局可视化所有集群状态。同时建立自动化故障转移流程，通过健康检查、故障检测和流量切换实现分钟级 RPO、秒级 RTO。

关键实践包括：DR 运行手册的定期演练、跨集群状态一致性保障、核心 ConfigMap/Secret 的中心化管理与审计追踪，以及 etcd 备份管理的自动化轮换。

七、渐进式实施路径

企业实施多集群策略应遵循渐进路径：先构建标准化的基础设施即代码（Terraform/Pulumi），再引入 GitOps 统一集群生命周期管理，然后建立多集群备份与容灾机制，最后逐步探索服务网格集成、多集群可观测平台和边缘计算场景。建议从最简单的 2-3 集群起步验证架构可行性，再根据业务需求稳步扩展。