从多集群权重到节点弹性：Kubernetes 混合云架构的落地路径

在多云环境中，Kubernetes 的"弹性"与"权重"经常被混为一谈。真正可落地的混合云架构，需要把副本调度、流量分配、节点伸缩拆到不同层次分别治理。

一、问题起点：每个云一个 K8s 集群，按权重跑业务可行吗？

一个常见的设想是：在阿里云、腾讯云、百度云各建一个 Kubernetes 弹性集群，然后通过权重把业务按比例分布到这些资源上。

结论是：可行，但必须先厘清"权重"作用在哪一层。

• 如果权重作用在副本数量上，它回答的是"后端容量放在哪个云"；
• 如果权重作用在用户流量上，它回答的是"请求先去哪个云"。

这两件事需要不同的技术层来实现。把二者混在同一个权重字段里，故障切换和容量重平衡都会变得僵硬。

二、权重调度的分层设计

2.1 副本权重：Karmada 的 PropagationPolicy

在开源多集群编排领域，Karmada 是当前最主流的事实标准。它允许用户继续编写标准 Kubernetes YAML，通过额外的分发策略声明副本该去哪些集群、按什么权重分配。

核心字段是 ReplicaSchedulingStrategy：

• replicaSchedulingType: Divided：将副本拆分到多个集群；
• replicaDivisionPreference: Weighted：按权重分配；
• weightPreference：支持静态权重和动态权重。

一个简化示例如下：

 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 个副本。动态权重则可由 Karmada 根据各集群可用容量自动计算比例。

需要明确的是：这个权重只作用于副本数量，不直接控制用户请求流向。

2.2 流量权重：GSLB 或服务网格

如果目标是"70% 的用户请求进入阿里云集群"，就需要在入口层增加全局负载均衡能力。

• K8gb：基于 DNS 实现跨集群加权流量，适合稳态比例分配，但受 DNS 缓存影响，不适合秒级故障熔断；
• 云厂商 GSLB / 多集群网关：运维负担低，但会与厂商入口层产生一定绑定；
• Istio 多集群：适合东西向服务调用的精细切流，支持按请求内容、地域、故障状态动态调整，但需要打通东西向网络，复杂度更高。

2.3 主流选型收敛

如果只追求"最主流"，答案可以收敛为两条：

• 开源自管：Karmada。CNCF 多集群编排领域的事实标准，生产案例覆盖阿里云、华为、京东云、快手、B 站、携程、vivo 等，不绑定单一云厂商；
• 托管省心：阿里云 ACK One。底层核心即 Karmada，可将其他云和 IDC 的 K8s 集群注册接入，在舰队层做静态/动态权重分发，适合运维资源有限、能接受以阿里云作为管控入口的团队。

Cluster API 管的是"集群如何创建和升级"，Karmada / ACK One 管的是"业务副本如何按权重落到集群上"，两者不在同一层，不构成直接竞争。

三、跨云网络：权重之前先打通"路"

多云集群最容易在落地时卡住的一环是东西向网络。Karmada 把副本拆到三个云之后，如果微服务之间存在调用关系，Pod IP 默认跨云不可达。

主流打通方式有两类：

如果还需要 mTLS、重试、熔断、按请求内容切流，则需在连通性之上叠加 Istio 多集群，复杂度会显著上升。

一个务实的次序是：先确保副本权重调度出来的服务之间网络可达，再谈流量权重和精细治理。如果业务以南北向访问为主、服务间调用少，跨云网络压力会小很多。

四、节点弹性扩容的三条路径

跨云副本权重解决"副本去哪个云"，而每个云内部还需要解决"节点够不够"。Kubernetes 节点弹性扩容主流有三条路径。

4.1 Cluster Autoscaler：通用基线

CA 周期性检查因资源不足而 Pending 的 Pod，然后调用云厂商伸缩组增加节点；缩容时监测低利用率节点，空闲约 10 分钟后驱逐并释放。

特点：成熟、通用，但只能在预定义节点池内伸缩，扩容通常需要 3 到 4 分钟。

适用：GKE、存量集群、已有复杂伸缩组配置的环境。

4.2 Karpenter：更快、更按需

Karpenter 跳过节点组，直接监听 Pending Pod 的真实资源需求，调用云 API 创建最合适的实例，扩容通常在 30 到 60 秒级别。它还支持主动整合，把 Pod 重新打包到更少、更便宜的节点上。

边界：不能与 CA 同时安装；目前在 AWS EKS 和 Azure AKS 支持最佳；GCP 尚无官方 Karpenter Provider，GKE 仍应使用 CA。

适用：AWS / Azure 上的新建或可改造集群，实例规格需求多样、希望兼顾速度与成本。

4.3 虚拟节点：不扩真实节点的弹性延伸

虚拟节点通过 Virtual Kubelet 向集群注册一个"虚拟节点"，调度到该节点的 Pod 实际运行在云厂商的无服务器容器实例上（如阿里云 ECI、百度云 BCI、Azure ACI），不会创建真实 Worker 节点。

优势：近乎即时、按秒计费，适合无状态、突发型、短生命周期负载。

约束：通常需要通过 nodeSelector 或容忍度显式引导；有状态负载、本地存储、特殊内核参数的兼容性需逐项验证。

五、跨云弹性：FederatedHPA 与节点弹性不是一回事

需要特别区分两个层面：

• 单集群内部：CA、Karpenter、虚拟节点解决的是"节点数量"；
• 跨云集群之间：Karmada 的 FederatedHPA 解决的是"副本总数"。

FederatedHPA 从多个成员集群聚合指标，统一调整工作负载总副本数；伸缩后的副本再通过 PropagationPolicy 按权重分发到各云集群；各云集群内部的节点弹性组件再决定本地节点是否足够。

一句话概括：FederatedHPA 决定"要多少副本"，Karmada 权重策略决定"副本去哪个云"，各集群节点弹性组件决定"本地节点够不够"。

六、推荐的组合架构

一个更稳健的混合云模式应当是分层管控、各层解耦：

在单云内部，可以采用"稳态 + 突发"分层：少量托管节点承载有状态服务和基础设施组件；Karpenter 按需补充真实节点；虚拟节点承接无状态突发流量，避免为短时峰值常备真实节点。

七、落地路线建议

1. 先跑通最小闭环：用 Karmada 将两个云集群接入，配置一个 PropagationPolicy，验证副本按权重分发；
2. 补齐跨云网络：根据 CNI 和 CIDR 情况选择 Submariner 或 Cilium ClusterMesh，确保跨集群服务调用可达；
3. 接入节点弹性：AWS / Azure 优先评估 Karpenter，GKE 或存量环境继续使用 CA；无状态突发场景再叠加虚拟节点；
4. 再谈流量权重：在副本权重稳定后，用 GSLB 或服务网格承接南北向流量比例与故障切换；
5. 最后接入 FederatedHPA：在已有权重分发基础上验证跨集群副本伸缩。

八、总结

“每个云一个 K8s 集群 + 权重"并不是一个需要推翻的设想。Karmada 的加权副本分发已经可以跑通最小闭环，ACK One 则提供了托管化路径。

真正决定方案能否在生产跑稳的，往往不是权重本身，而是三件事：

• 权重作用在副本还是流量，是否分清；
• 跨云网络是否提前打通；
• 节点弹性与副本弹性是否分层治理。

把管控层、入口层、服务层、节点弹性层和副本弹性层拆开设计，比试图用一个工具扛下所有"权重"和"弹性"更可靠。