上一篇【第87篇】微服务应用K8s化改造实战——从传统部署到云原生下一篇【第89篇】K8s AI/ML——在K8s上运行机器学习工作负载摘要单集群玩得再溜也架不住业务真上规模——一个集群挂了全公司停摆、一个地域延迟高用户骂街、被一家云厂商锁死不敢动。这时候就得多集群。但多集群不是再装一个K8s那么简单应用怎么同时发到几个集群一个集群挂了流量怎么切走配置怎么保持一致这篇把多集群的核心动机、KubeFed v2的联邦模型、以及Karmada等现代方案一次讲清顺便聊聊跨集群服务发现和流量调度这些真正难的活。一、为什么需要多集群单集群的三道天花板先说清楚不是炫技才上多集群是单集群真有物理天花板【单集群的天花板】 1. 故障域单一 一个控制平面挂 → 整个集群失联(哪怕节点都活着) 一次etcd脑裂 → 全集群写入瘫痪 2. 地域延迟 集群在华东, 华南用户访问绕半圈 合规要求数据不出境(数据主权) 3. 厂商锁定 全在A云, 想迁B云? 重来一遍 某云region故障 → 业务全断由此引出多集群的三大驱动力要点多集群通常不是为了技术而是为了隔离故障域、贴近用户、不绑定单一厂商。先把动机想清楚再选方案不然容易为联邦而联邦。驱动力典型场景架构形态高可用/灾备主集群挂了切备用同城双活 / 异地灾备低延迟用户分散多地域多地域就近接入混合云/多云不绑定厂商、用便宜资源自有IDC 公有云二、KubeFed v2联邦控制面长啥样KubeFedKubernetes Federation v2是社区早期的联邦方案思路很清晰再起一个联邦控制面它去管你底下的一堆成员集群。【KubeFed 架构】 ┌─────────────────────────────┐ │ 联邦控制面 (Federation) │ │ ┌───────────────────────┐ │ │ │ federated-apiserver │ │ │ │ federated-controller │ │ │ └───────────────────────┘ │ └───────┬───────────┬─────────┘ │ │ ┌─────▼───┐ ┌────▼─────┐ │ 集群A │ │ 集群B │ ← 普通K8s集群, 各自独立 │(华东) │ │(华北) │ └─────────┘ └──────────┘核心概念三个FederatedTypeConfig告诉联邦我要管哪些资源类型Deployment/Service/ConfigMap…。不配置的就不联邦。FederatedResource如FederatedDeployment在普通Deployment外面套一层描述这个Deployment要发到哪些集群、各发几份。Placement / ReplicaSchedulingPreference决定分发策略——发到哪几个集群、副本怎么分配。一个FederatedDeployment长这样apiVersion:types.kubefed.io/v1beta1kind:FederatedDeploymentmetadata:name:order-servicenamespace:shopspec:template:# 这就是普通的Deployment specmetadata:labels:{app:order-service}spec:replicas:6template:spec:containers:-name:order-serviceimage:registry.example.com/order-service:1.5.0placement:clusters:-name:cluster-east# 发到华东-name:cluster-north# 发到华北overrides:-clusterName:cluster-eastclusterOverrides:-path:/spec/replicasvalue:4# 华东放4副本-clusterName:cluster-northclusterOverrides:-path:/spec/replicasvalue:2# 华北放2副本(用户少)要点KubeFed的优雅之处在于**“声明一次多集群落地”**——你只写一份FederatedDeployment联邦控制器帮你把真正的Deployment同步到每个成员集群还能按集群差异化覆盖副本数、镜像等。三、副本怎么分ReplicaSchedulingPreference光指定发到哪不够副本怎么切也讲究。RSPReplicaSchedulingPreference支持按权重、按集群容量动态分配apiVersion:scheduling.kubefed.io/v1alpha1kind:ReplicaSchedulingPreferencemetadata:name:order-servicenamespace:shopspec:targetKind:FederatedDeploymenttotalReplicas:10clusters:cluster-east:weight:3# 华东权重3cluster-north:weight:1# 华北权重1# 结果: 华东 7.5→8, 华北 2.5→2 (按权重近似)这比手工写固定副本数灵活集群扩缩容后权重自动再平衡。四、KubeFed的尴尬与现代替代Karmada说实话KubeFed v2到后来社区基本停滞了——它侵入式地要求你改YAML写FederatedXxx而且跨集群服务发现、流量治理这种硬骨头它没解决好。于是出现了更现代的方案代表是Karmada。【Karmada 思路: 更接近多集群的K8s】 Karmada 控制面 ├── karmada-apiserver (兼容K8s API!) ├── karmada-scheduler (把资源调度到成员集群) └── karmada-controller 关键差别: 你写的还是原生 Deployment/Service YAML! 只是通过 PropagationPolicy 决定发到哪些集群 → 不用学一套新API, 迁移成本低# 原生Deployment照写, 另外配一个分发策略apiVersion:policy.karmada.io/v1alpha1kind:PropagationPolicymetadata:name:order-propnamespace:shopspec:resourceSelectors:-apiVersion:apps/v1kind:Deploymentname:order-serviceplacement:clusterAffinity:clusterNames:[cluster-east,cluster-north]spreadConstraints:-spreadByField:clustermaxGroups:2# 至少分到2个集群要点Karmada相比KubeFed最大的进步是**“API兼容”**——你继续写原生K8s YAML用一份PropagationPolicy描述分发意图不用把每个资源都改写成Federated类型。这也是它现在更受欢迎的原因。五、真正难的活跨集群服务发现与流量联邦把资源分发解决了但用户访问时的问题是我该打到哪个集群集群A挂了怎么切到B【跨集群流量调度】 用户 │ ▼ 全局负载均衡(GSLB / DNS 按地域) │ ├── 华东用户 → 集群A Ingress └── 华北用户 → 集群B Ingress 集群间: - 服务发现: 各集群独立Service, 靠外部GSLB分流 - 数据同步: 数据库主从/多活(不在K8s职责内) - 故障切换: 健康检查失败 → DNS/Anycast切走主流做法分两层南北向用户→集群靠云厂商GSLB、DNS按地域解析、或Cloudflare/Alb等做全局流量管理。集群挂了就把解析切走。东西向集群↔集群如果集群间要互相调用用Cilium Cluster Mesh或Submariner第050篇讲过的多集群网络打通Pod网络让A集群的Pod能直接访问B集群的Service。要点多集群的难不在分发在状态与流量。无状态服务好办分发GSLB有状态服务数据库的多活/主从才是噩梦——这部分通常不在K8s层解决而靠数据库自身的主从复制。六、多集群可观测性多个集群监控也不能各看各的。常见两种思路方案做法适合全局Prometheus各集群remote-write到中心Prometheus集群数不多、网络稳Thanos / Cortex各集群Prometheus本地存全局查询层聚合大规模、长期存储多集群Grafana一个Grafana配多个数据源轻量统一看板# 各成员集群的Prometheus加remoteWrite(示例)global:remote_write:-url:http://thanos-receiver.federation.svc:19291/api/v1/receive七、选型建议你的处境推荐只是灾备用平时一个主一个备主备 Velero定期备份(第082篇)别上联邦多地域低延迟无状态服务多GSLB分流 Karmada分发混合云不想绑定厂商Karmada 各云原生CSI/CNI集群间要Pod直连调用Cilium Cluster Mesh / Submariner(第050篇)只是想统一管理kubectlkubectl context 切换 轻量面板即可要点很多团队一上来就上联邦结果90%的集群从来不会切换纯增加复杂度。先问真有多集群故障切换需求吗没有就主备备份够了别为联邦而联邦。本篇小结多集群是单集群撞上故障域、地域延迟、厂商锁定三道天花板后的必然选择。KubeFed v2用联邦控制面一套Federated资源实现了声明一次多集群落地但侵入式API和跨集群服务治理短板让它逐渐边缘化Karmada用原生YAML PropagationPolicy的兼容思路成了更主流的现代方案。但要记住分发容易流量和状态难。无状态服务靠GSLB分流联邦分发即可有状态服务多活才是硬骨头。别为了联邦而联邦——没真实切换需求主备Velero备份往往更省心。下篇换个重话题在K8s上跑AI/ML工作负载。上一篇【第87篇】微服务应用K8s化改造实战——从传统部署到云原生下一篇【第89篇】K8s AI/ML——在K8s上运行机器学习工作负载