跳至主要內容

Kubernetes 多集群管理实战——Kubefed、Rancher、Crossplane 选型对比

老张2026/4/30大约 6 分钟

Kubernetes 多集群管理实战——Kubefed、Rancher、Crossplane 选型对比

适读人群：面临多集群管理挑战的工程师，在选型多集群方案的人 | 阅读时长：约 16 分钟 | 核心价值：三种主流多集群方案的真实对比，帮你做出合适的选型决策

我第一次遇到多集群需求，是因为公司业务扩张到了海外。

当时我们在国内有一个 K8s 集群跑得很稳，但要在新加坡再开一个集群服务东南亚用户。两个集群，配置要保持基本一致（相同的服务、相同的基础设施组件），但也要有差异（不同的域名、不同的数据库、合规要求不同）。

最开始我们靠人工维护，同样的改动在两个集群各做一遍。半年下来，两个集群的配置已经悄悄漂移了——某些告警规则只在一个集群更新了，某些 RBAC 配置也不同步……

这才开始认真研究多集群管理方案。

为什么会有多集群？

先理清楚为什么会出现多集群，因为不同场景对应不同的解决方案：

原因典型场景关注点
地理分布多 Region 部署、就近访问流量路由、数据合规
环境隔离dev/staging/production 分集群配置一致性
业务隔离不同 BU 用不同集群权限隔离、独立计费
高可用集群故障时快速切换跨集群故障转移
规模限制单集群 Node 数量/Pod 数量有上限横向扩展

我们的场景是"地理分布 + 环境隔离"，最终选型了 Rancher。

方案一：Kubefed（Kubernetes Federation）

基本介绍

Kubefed（Kubernetes Cluster Federation）是 CNCF 的官方多集群联邦方案，通过 FederatedDeployment、FederatedService 等自定义资源，把配置推送到多个成员集群。

安装和使用

# 安装 Kubefed（需要 host cluster）
helm repo add kubefed-charts https://raw.githubusercontent.com/kubernetes-sigs/kubefed/master/charts
helm install kubefed kubefed-charts/kubefed \
    --namespace kube-federation-system \
    --create-namespace

# 将成员集群加入联邦
kubefedctl join cluster-sg \
    --cluster-context=arn:aws:eks:ap-southeast-1:xxx \
    --host-cluster-context=arn:aws:eks:cn-north-1:xxx \
    --v=2

Kubefed 资源示例（Federated Deployment）：

apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
  name: user-service
  namespace: production
spec:
  template:
    metadata:
      labels:
        app: user-service
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: user-service
      template:
        spec:
          containers:
          - name: user-service
            image: registry.example.com/user-service:v2.3.1
  
  placement:
    clusters:
    - name: cluster-cn
    - name: cluster-sg
  
  overrides:
  # 为新加坡集群覆盖副本数
  - clusterName: cluster-sg
    clusterOverrides:
    - path: "/spec/replicas"
      value: 2

踩坑实录一：Kubefed 社区活跃度下降，版本更新停滞

现象：我们评估 Kubefed v0.9 时，发现其 GitHub 仓库上次 release 是 9 个月前，issue 积压严重，部分 K8s 新特性（1.25+）不支持。

原因：Kubefed 属于 SIG-Multicluster 负责维护，但实际上这个 SIG 的精力主要放到了新的 Work API（MCS API）上，Kubefed 进入了维护模式。

结论：Kubefed 不推荐在新项目里使用，适合已经在用且无法迁移的场景。更推荐关注 Karmada（华为维护，Kubefed 的精神继承者，社区活跃）。

方案二：Rancher

基本介绍

Rancher 是 SUSE 旗下的 K8s 管理平台，提供 Web UI + API 来统一管理多个 K8s 集群（包括 EKS、GKE、AKS 等云厂商集群，以及自建集群）。

功能包括：

  • 多集群可视化管理（Dashboard）
  • 跨集群的用户/权限管理（RBAC 同步）
  • 应用商店（基于 Helm Chart）
  • 集群监控和日志（集成 Prometheus/Grafana/Loki）
  • Pipeline CI/CD

安装 Rancher

# 安装 cert-manager（Rancher 依赖）
helm install cert-manager jetstack/cert-manager \
    --namespace cert-manager \
    --set installCRDs=true

# 安装 Rancher
helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
helm install rancher rancher-stable/rancher \
    --namespace cattle-system \
    --create-namespace \
    --set hostname=rancher.example.com \
    --set bootstrapPassword=InitialPassword123!

将已有集群导入 Rancher

# 在 Rancher UI 里点 "Import Existing Cluster"，获取 kubectl 命令
# 然后在目标集群上执行（Rancher 会在目标集群安装 cattle-cluster-agent）
kubectl apply -f https://rancher.example.com/v3/import/xxx.yaml

Rancher 多集群策略（Fleet）

Rancher 2.6+ 内置了 Fleet（GitOps 多集群管理），可以把一套配置统一分发到多个集群：

# fleet/apps/user-service/fleet.yaml
defaultNamespace: production

helm:
  chart: user-service
  repo: https://charts.example.com
  version: "1.3.2"
  releaseName: user-service
  values:
    image:
      tag: "v2.3.1"
    replicaCount: 3

# 覆盖特定集群的配置
targetCustomizations:
- name: singapore
  clusterSelector:
    matchLabels:
      region: ap-southeast-1
  helm:
    values:
      replicaCount: 2
      ingress:
        host: "api-sg.example.com"

方案三：Crossplane

基本介绍

Crossplane 的定位和前两者不同——它不是一个管理平台，而是一个云资源管控工具，可以用 K8s CRD 来声明式管理云资源（AWS EC2、RDS、EKS 集群、GCP GKE 等）。

用 Crossplane 可以做到：用 kubectl apply 创建一个 EKS 集群，用 K8s YAML 描述所有云基础设施。

# 用 Crossplane 创建 EKS 集群
apiVersion: eks.aws.crossplane.io/v1beta1
kind: Cluster
metadata:
  name: production-sg
spec:
  forProvider:
    region: ap-southeast-1
    version: "1.28"
    roleArnRef:
      name: eks-cluster-role
  providerConfigRef:
    name: aws-provider

Crossplane 更适合"基础设施即代码"的场景，不太适合纯粹的"多集群管理"需求。

踩坑实录二：多集群网络互通的挑战

现象：两个集群部署了同一服务，但服务 A（cluster-cn）需要调用服务 B（cluster-sg）。两个集群都是私有网络，Pod 的 CIDR 不互通。

解法方案：

方案 1：通过 Ingress + 公网 LoadBalancer（最简单，但有延迟和费用）

方案 2：VPN 打通两个 VPC（适合同一云厂商）

方案 3：Istio 多集群服务网格（最优雅，但最复杂）

# Istio 多集群：在两个集群间建立信任
# cluster-cn 可以访问 cluster-sg 的 service B
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: service-b-sg
  namespace: production
spec:
  hosts:
  - "service-b.production.svc.cluster.sg"
  location: MESH_EXTERNAL
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS
  endpoints:
  - address: sg-cluster-istio-ingressgateway.example.com
    ports:
      http: 15443

踩坑实录三：多集群 RBAC 同步困难

现象：给团队成员配置了 cluster-cn 的权限，但他们无法访问 cluster-sg，需要手动在两个集群各配一遍，很容易不同步。

解法：

  • 用 Rancher：用户权限在 Rancher 层统一配置，自动同步到所有成员集群
  • 用 LDAP/OIDC 统一身份源：两个集群都对接同一个身份认证系统，权限各自配置但用户统一
  • 用 Kyverno/OPA 策略引擎：在多个集群上统一执行 RBAC 策略

选型建议

场景推荐方案原因
小团队，2~5 个集群，需要 UIRancher开箱即用，UI 友好，学习成本低
GitOps 已有 ArgoCD，想统一多集群ArgoCD + ApplicationSet沿用现有工具链，ApplicationSet 支持多集群分发
大规模，20+ 集群，精细控制Karmada社区活跃，功能最全，但学习成本高
基础设施即代码，创建和管理云资源Crossplane定位不同，适合 PlatformOps 团队
已经在用 Kubefed逐步迁移到 KarmadaKubefed 社区不活跃

最后说句实话：多集群管理是 K8s 里复杂度最高的方向之一，没有合适的运维团队和技术储备，不要轻易引入。如果只有 2~3 个集群，很多时候靠 ArgoCD + 规范化的 Helm Chart 就够了，不必引入专门的多集群管理平台。

编辑此页
最近更新:
贡献者: xiaozhangge