跨云 Kubernetes 架构实战：弹性扩容、网络与存储的落地路径
多云 Kubernetes 的真正难点，不在于"把集群建起来"，而在于弹性扩容、跨云网络和持久化存储这三层基础设施的设计。Karmada 解决了副本调度，但它不替你打通网络、也不替你同步数据。
一、问题起点：多云 K8s 的三个真实挑战
一个常见的设想是：在阿里云、腾讯云、百度云各建一个 Kubernetes 集群，然后通过权重把业务按比例分布到这些资源上。
副本权重调度在 Karmada 中已有成熟的声明式实现，但落地时会依次遇到三个不在 Karmada 管辖范围内的问题：
- 弹性扩容：副本分过去了，节点够不够？突发流量来了怎么扩？
- 跨云网络：三个云的 Pod 之间默认互不可达，服务调用怎么通？
- 持久化存储：PV 绑定在本地，跨云怎么备份、怎么恢复、怎么高可用？
这三个问题需要独立设计、分层解决。下面逐一展开。
二、弹性扩容：副本弹性与节点弹性必须分层
2.1 先厘清两个层面
- 副本弹性：跨多个云集群，决定"总共要多少副本"——由 Karmada 的 FederatedHPA 负责；
- 节点弹性：单个集群内部，决定"本地节点够不够"——由 Cluster Autoscaler、Karpenter 或虚拟节点负责。
一句话概括：FederatedHPA 决定"要多少副本"，Karmada 权重策略决定"副本去哪个云"，各集群节点弹性组件决定"本地节点够不够"。
2.2 副本权重调度：Karmada PropagationPolicy
Karmada 允许用户继续编写标准 Kubernetes YAML，通过 PropagationPolicy 声明副本该去哪些集群、按什么权重分配：
1apiVersion: policy.karmada.io/v1alpha1
2kind: PropagationPolicy
3metadata:
4 name: business-policy
5spec:
6 resourceSelectors:
7 - apiVersion: apps/v1
8 kind: Deployment
9 name: business-service
10 placement:
11 clusterAffinity:
12 clusterNames: [aliyun, tencent, baidu]
13 replicaScheduling:
14 replicaSchedulingType: Divided
15 replicaDivisionPreference: Weighted
16 weightPreference:
17 staticWeightList:
18 - targetCluster:
19 clusterNames: [aliyun]
20 weight: 5
21 - targetCluster:
22 clusterNames: [tencent]
23 weight: 3
24 - targetCluster:
25 clusterNames: [baidu]
26 weight: 2
总副本数为 10 时，三个集群分别得到 5、3、2 个副本。也可以启用动态权重（dynamicWeight: AvailableReplicas），由 Karmada 根据各集群可用容量自动计算比例。
关键认知：这个权重只作用于副本数量，不直接控制用户请求流向。流量层的权重需要 GSLB 或服务网格来承接。
2.3 节点弹性：三条路径
| 方案 | 扩容速度 | 核心机制 | 最适合 |
|---|---|---|---|
| Cluster Autoscaler | 较慢（约 3–4 分钟） | 节点组/伸缩组 | 通用基线、GKE、存量集群 |
| Karpenter | 较快（约 30–60 秒） | 直接调云 API，按 Pod 需求选实例 | AWS/Azure 新集群，追求速度与成本 |
| 虚拟节点 | 近乎即时（无节点创建） | Virtual Kubelet → 无服务器容器实例 | 无状态突发、短生命周期负载 |
Cluster Autoscaler 周期检查 Pending Pod，调用云厂商伸缩组增加节点；但只能在预定义节点池内伸缩，扩容偏慢。Karpenter 跳过节点组直接按 Pod 真实需求创建最合适的实例，速度显著更快，还支持主动整合把 Pod 重新打包到更少、更便宜的节点上；目前 AWS EKS 和 Azure AKS 支持最佳，GCP 尚无官方 Provider。虚拟节点通过 Virtual Kubelet 把 Pod 调度到云厂商的无服务器容器实例（阿里云 ECI、百度云 BCI、Azure ACI），不创建真实节点，适合无状态突发负载。
2.4 推荐的弹性分层组合
单云内部采用"稳态 + 突发"分层：少量托管节点承载有状态服务和基础设施组件；Karpenter 按需补充真实节点；虚拟节点承接无状态突发流量，避免为短时峰值常备真实节点。跨云层面，用 FederatedHPA 统一调整总副本数，再由 PropagationPolicy 按权重分发。
需要区分的边界：CA、Karpenter、虚拟节点解决的是单集群内的节点数量；FederatedHPA 解决的是跨集群的副本总数。两者不是替代关系，而是不同层次。
三、跨云网络：底层连通与 K8s 层互通，缺一不可
3.1 第一层：云与云之间的底层连通
| 方式 | 性能与可靠性 | 成本 | 适用场景 |
|---|---|---|---|
| VPN（IPsec） | 延迟波动大，依赖公网 | 低 | 非核心业务、初期验证、小带宽 |
| 专线（Direct Connect/ExpressRoute） | 低延迟、带宽稳定、有 SLA | 高 | 核心业务、大数据量、合规要求 |
| SD-WAN | 灵活聚合多条链路，可智能选路 | 中等 | 多站点、需要灵活性和成本优化 |
务实做法：核心生产链路走专线，非核心或灾备链路用 VPN 兜底，两者组合是混合云网络最常见的基线。
3.2 第二层：Kubernetes 跨集群服务互通
底层通了不代表 Pod IP 之间就能直接通信。Kubernetes 的 Service/DNS 是集群内概念，跨云服务调用需要额外方案。
Submariner：CNI 无关，通过 IPsec/WireGuard 隧道在集群间建立 L3 连通，借助 ServiceExport 和 clusterset.local 域名实现跨集群服务发现。多云异构环境（各云 CNI 不同）的首选，通用性最强。
Cilium ClusterMesh：基于 eBPF，性能最优、额外跳数最少，但要求所有集群都使用 Cilium 作为 CNI。如果多云集群能做到 CNI 统一，这是性能最好的路径。
选型原则：各云 CNI 不统一 → Submariner；能统一上 Cilium → ClusterMesh。如果需要 mTLS 和精细流量治理，再在连通性之上叠加 Istio 多集群，复杂度会显著上升。
3.3 跨云统一入口：VIP 能不能跨云？
传统 Keepalived VIP 依赖 VRRP 的二层广播域，公有云 VPC 之间是三层路由隔离，传统 VIP 漂移在跨云场景下无法直接实现。云厂商的 HaVIP 或弹性 IP 也只服务于同一个 VPC 内部或跨可用区。
真正能承载跨云统一入口的有两种方式：
BGP Anycast（网络层）：多个云的数据中心同时向公网宣告同一个 IP，流量自动导向最近的健康节点。故障时停止宣告，流量收敛到其他节点，IP 本身不变。前提是你需要拥有可宣告的公网 IP 段和 ASN，或者使用支持 Anycast 的云厂商 EIP 产品。
GSLB/全局负载均衡（应用层）：用一个逻辑统一入口（域名或全局负载均衡器）替代网络层 VIP，后端挂载多个云各自的存储网关或代理节点。实现门槛远低于 Anycast，代价是切换速度取决于 DNS TTL 或健康检查间隔。
务实建议：如果追求入口 IP 完全不变，评估 BGP Anycast；如果更看重落地成本和可控性，用 GSLB 做逻辑统一入口，这是跨云更现实的基线。
四、持久化存储：单集群持久化与跨云数据韧性
Karmada 本身不处理存储，PV/PVC 绑定在本地后难以跨云迁移。存储需要分两件事来做。
4.1 单集群内部的持久化
Rook + Ceph 是混合云场景下最成熟的开源选择。Rook 作为 CNCF 毕业的 Operator，通过 CSI 驱动把 PVC 翻译成 Ceph RBD 块存储或 CephFS 文件存储，自动处理供给、挂载、快照和删除。如果云厂商提供了托管 CSI（如阿里云云盘 CSI、腾讯云 CBS CSI），运维要求更低，但会与具体云绑定。
4.2 跨云异步复制方案
跨云场景下，有状态的核心难点不是"存储卷能否迁移"，而是"数据能否在目标云恢复"。按存储类型分层选型：
块存储层：Ceph RBD Mirroring 支持两种模式——Journal-based（基于日志，接近崩溃一致的点对点复制，写入延迟几乎翻倍）和 Snapshot-based（基于快照的周期性增量复制，对性能影响小，RPO 取决于快照频率）。Longhorn DR Volumes 适合 Kubernetes 原生环境，通过共享备份目标（S3 兼容对象存储或 NFS）实现跨集群异步复制，灾备卷保持 Standby 只读状态，需要时手动激活。DRBD 原生支持异步协议，跨云高延迟场景通常需要叠加 DRBD Proxy 缓冲复制流量。
文件与对象层：云厂商对象存储的跨区域复制（如阿里云 OSS CRR、腾讯云 COS 跨地域复制）几乎开箱即用，自动异步复制对象的创建、更新和删除。自建对象存储用 MinIO 的服务端异步复制。文件系统层面，rsync + lsyncd 是经典组合，轻量通用，但本质是文件级覆盖，更适合单向灾备。
Kubernetes 持久化卷层：Velero 是事实标准，可用 Restic 或 Kopia 对 PV 做文件级备份异步推送到对象存储。推荐组合是"高频本地 CSI 快照 + 低频 Restic 备份到 S3"，兼顾恢复速度和跨云可用性。
数据库层：对于有状态的核心业务，与其在存储层跨云硬扛，不如在数据库层做异步复制（MySQL binlog、PostgreSQL WAL 或逻辑复制），RPO 和运维手段更清晰。这通常比让数据库跑在跨云存储卷上更稳健。
4.3 跨云存储高可用的务实架构
真正存储数据的组件通常不应该跨云组成一个统一的存储集群。跨云高延迟和网络抖动会让 Ceph 的 OSD 心跳、PG 同步变得非常脆弱，Longhorn 的跨云副本也会因为网络分区频繁触发重建。
更务实的架构是：每个云内部署一套独立的存储服务（或存储网关），数据通过异步复制或备份保持最终一致；跨云的统一入口（Anycast 或 GSLB）只负责把客户端请求路由到当前健康的那一套存储端点，而不是让客户端直连一个横跨三朵云的存储集群。
统一入口只解决"请求去哪"，不解决"数据在不在那里"。数据一致性仍然需要在存储层或数据库层单独设计。
五、整体架构分层参考
| 层次 | 职责 | 可选技术 |
|---|---|---|
| 管控层 | 集群注册、策略分发、副本权重 | Karmada、ACK One |
| 副本弹性层 | 跨集群副本总数伸缩 | Karmada FederatedHPA |
| 入口层（南北向） | 用户流量加权与故障切换 | K8gb、云厂商 GSLB、BGP Anycast |
| 服务层（东西向） | 跨集群服务调用与治理 | Submariner、Cilium ClusterMesh、Istio |
| 节点弹性层 | 单集群节点伸缩 | CA、Karpenter、虚拟节点 |
| 存储层 | 单集群持久化 + 跨云异步复制 | Rook+Ceph、Longhorn DR、Velero、对象存储 CRR |
六、落地路线建议
- 先跑通最小闭环：用 Karmada 将两个云集群接入，配置 PropagationPolicy 验证副本按权重分发；
- 补齐跨云网络：底层专线/VPN 打通后，根据 CNI 情况选择 Submariner 或 Cilium ClusterMesh，确保跨集群服务调用可达；
- 接入节点弹性：AWS/Azure 优先评估 Karpenter，GKE 或存量环境继续使用 CA；无状态突发场景再叠加虚拟节点；
- 规划存储韧性：每个集群配好 Rook/Ceph 或托管 CSI，跨云用 Velero 备份 + 数据库层异步复制，不要试图让存储集群跨云统一部署；
- 再谈流量权重与统一入口：在副本权重稳定后，用 GSLB 或 BGP Anycast 承接南北向流量比例与故障切换；
- 最后接入 FederatedHPA：在已有权重分发基础上验证跨集群副本伸缩。
七、总结
“每个云一个 K8s 集群 + 权重"并不是一个需要推翻的设想。Karmada 的加权副本分发已经可以跑通最小闭环。真正决定方案能否在生产跑稳的，往往是三件不在 Karmada 管辖范围内的事：
- 弹性扩容是否分层治理：副本弹性（FederatedHPA）与节点弹性（CA/Karpenter/虚拟节点）各司其职；
- 跨云网络是否提前打通：底层专线/VPN 是前提，K8s 层用 Submariner 或 ClusterMesh 补服务发现；
- 存储是否接受"各云独立 + 异步复制”：不要让存储集群跨云统一部署，数据一致性在存储层或数据库层单独设计。
把管控、弹性、网络、存储拆开分层设计，比试图用一个工具扛下所有问题更可靠。