多集群管理思路与实践

摘要：本文先讨论「什么时候真的需要多集群」，再给出三种典型拓扑，最后落地到实操：用 kubectl 多上下文管理、用 GitOps 统一分发配置、用联邦方案做跨集群调度。

适用环境

两个及以上 K8s 集群（可用 kind 起两个本地集群练习）
kubectl 已安装
可选：Argo CD / Flux、KubeFed / Karmada / OCM

操作步骤

一、先判断：你真的需要多集群吗

多集群会显著提高复杂度（网络、身份、配置同步、监控聚合）。真正合理的理由：

理由	说明
故障域隔离	单集群炸了不影响全部业务
地域就近	用户分布多地，降低延迟
合规与数据驻留	数据不能出特定区域
环境硬隔离	生产与测试绝不能互相影响
规模上限	单集群节点/Pod 数触及上限

注意

「为了高可用上多集群」却把两个集群放在同一个可用区同一台物理机上，是典型的自欺欺人。故障域必须真实独立。

二、三种典型拓扑

拓扑	结构	适用
主备（Active-Standby）	备集群常驻最小副本，故障切换	容灾，成本较低
双活（Active-Active）	两地同时承担流量	延迟敏感、成本充足
中心-边缘	中心管控 + 边缘集群执行	门店/工厂/边缘计算

三、用 kubectl 管理多个集群

bash

kubectl config get-contexts
kubectl config current-context
kubectl config use-context cluster-prod
kubectl config rename-context <旧名> <新名>

用 KUBECONFIG 环境变量合并多个配置文件：

bash

export KUBECONFIG=$HOME/.kube/config-prod:$HOME/.kube/config-test
kubectl config view --flatten > $HOME/.kube/config
kubectl config get-contexts

跨集群执行同一条命令：

bash

for ctx in cluster-prod cluster-test; do
  echo "===== $ctx ====="
  kubectl --context=$ctx get nodes
  kubectl --context=$ctx get pod -A | grep -v Running
done

建议

每次执行带 --context 显式指定目标集群。依赖「当前上下文」是误操作生产集群的头号原因。

四、用 GitOps 统一分发配置（推荐方案）

思路：集群不直接手改，全部由 Git 仓库声明，各集群的 Agent 拉取并应用。

Argo CD 示例：

bash

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
kubectl -n argocd get svc argocd-server

用 ApplicationSet 一次把同一应用发到多个集群：

yaml

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: web-appset
  namespace: argocd
spec:
  generators:
    - list:
        elements:
          - cluster: prod-sh
            url: https://10.0.1.10:6443
          - cluster: prod-bj
            url: https://10.0.2.10:6443
  template:
    metadata:
      name: 'web-{{cluster}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/example/k8s-manifests.git
        targetRevision: main
        path: apps/web
      destination:
        server: '{{url}}'
        namespace: default
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

优势：配置可评审、可追溯、可一键回滚，天然保证多集群一致性。

五、联邦方案对比

方案	定位
KubeFed	老牌联邦，资源分发为主
Karmada	华为开源，支持跨集群调度与故障迁移
OCM (Open Cluster Management)	Red Hat 主导，偏集群生命周期管理
Cluster API	用声明式方式创建和管理集群本身

六、跨集群网络与流量切换

text

DNS（按地域/健康解析） → 全局负载均衡 → 各集群 Ingress → Service → Pod

多集群 Service 互访（东西向）需要额外方案：Submariner、Cilium ClusterMesh，或直接走公网 Ingress。

危险

跨集群流量切换前必须确认数据层已做好同步/复制。只切流量不做数据同步，会造成双写冲突和数据丢失，这是多集群容灾最容易踩的坑。

七、统一可观测

bash

# 每个集群部署采集器，指标汇总到中心 Prometheus/存储
kubectl --context=cluster-prod -n monitoring get pod
kubectl --context=cluster-test -n monitoring get pod

关键：指标必须带 cluster 标签，否则聚合后无法区分来源。

八、权限与凭据管理

每个集群独立 RBAC，不要共用超级管理员 kubeconfig；
凭据集中托管并定期轮换；
用短期 token 而非长期证书。

验证

[ ] kubectl config get-contexts 能看到所有集群
[ ] 循环脚本能一次巡检多个集群
[ ] GitOps 修改仓库后两个集群都自动同步
[ ] 监控指标可按 cluster 维度区分

常见坑

误操作生产集群：未显式指定 --context，见上文建议。
配置漂移：手动改了一个集群，GitOps 自愈会覆盖回来，或长期不同步导致差异累积。
以为多集群就等于高可用：应用本身不支持多写、数据没同步，切换后照样不可用。
监控数据混在一起无法区分：缺少 cluster 标签。
跨集群 Service 名冲突：东西向打通后同名 Service 会互相干扰，需规划命名空间。

多集群管理思路与实践 ​

适用环境 ​

操作步骤 ​

一、先判断：你真的需要多集群吗 ​

二、三种典型拓扑 ​

三、用 kubectl 管理多个集群 ​

四、用 GitOps 统一分发配置（推荐方案） ​

五、联邦方案对比 ​

六、跨集群网络与流量切换 ​

七、统一可观测 ​

八、权限与凭据管理 ​

验证 ​

常见坑 ​

参考资料 ​

多集群管理思路与实践

适用环境

操作步骤

一、先判断：你真的需要多集群吗

二、三种典型拓扑

三、用 kubectl 管理多个集群

四、用 GitOps 统一分发配置（推荐方案）

五、联邦方案对比

六、跨集群网络与流量切换

七、统一可观测

八、权限与凭据管理

验证

常见坑

参考资料