📚 课程目录第2章多集群架构基础

基于多集群的多租户签名链路接口调用与故障恢复 - 第2节

2.1 从单集群到多集群：为什么需要多集群架构

随着业务规模增长与合规要求细化，单一 Kubernetes 集群在隔离性、故障半径、地域延迟和资源配额方面逐渐暴露出瓶颈。多集群架构的核心目标是在不牺牲运维效率的前提下，将工作负载分散到多个物理或逻辑集群中，实现故障隔离、数据合规与弹性伸缩。

维度	单集群局限	多集群优势
故障域	控制面或 etcd 故障影响所有租户	故障半径限制在单个集群内，其他集群继续服务
租户隔离	Namespace + RBAC 隔离，仍共享 kube-apiserver	物理集群隔离，租户拥有独立控制面与审计边界
地域延迟	所有 Pod 调度在同一区域，跨区延迟高	按地域就近调度，降低用户访问延迟
资源配额	集群总资源上限固定，扩容需重建集群	按需添加集群，资源池线性扩展
版本升级	蓝绿升级成本高，回滚影响全局	逐个集群滚动升级，风险可控

架构决策提示： 多集群不是银弹。如果团队规模小于 20 人、集群节点少于 50 个，优先考虑单集群 + 强 Namespace 隔离；当租户数量超过 10 个或需要跨 Region 部署时，才引入多集群管理平面。

2.2 联邦集群：统一控制面的经典模式

联邦集群（Federation）通过一个逻辑控制面将多个 Kubernetes 集群抽象为单一资源池。KubeFed（Kubernetes Federation v2）是当前主流实现，它使用 Federated API 类型 将 Deployment、Service、ConfigMap 等资源同步到成员集群。

2.2.1 联邦集群核心组件

Host Cluster（宿主集群）：运行 KubeFed 控制面组件，包括 federation-apiserver、federation-controller-manager。
Member Cluster（成员集群）：被纳管的业务集群，每个集群需安装 kubefed 插件并注册到 Host Cluster。
FederatedTypeConfig：定义哪些 API 资源可以被联邦同步，以及同步策略（push / pull）。
Placement Policy：决定资源分发到哪些成员集群，支持标签选择器与集群黑名单。
Override Policy：允许针对不同集群覆盖资源字段，例如调整副本数或镜像版本。

  关键流程： 用户在 Host Cluster 创建 FederatedDeployment → KubeFed 控制器根据 Placement 策略将资源推送到目标 Member Cluster → 每个 Member Cluster 的本地控制器将 Federated 对象转换为原生 Deployment 并调度 Pod。

2.2.2 联邦集群的适用场景与局限

场景	联邦集群优势	潜在风险
多集群统一部署	一次提交，多集群生效	网络分区时 Host Cluster 成为单点
跨集群 Service 发现	FederatedService 自动生成 DNS 记录	跨集群流量调度依赖外部负载均衡器
灰度发布	Override Policy 控制每个集群的副本比例	回滚需要逐个集群清理，操作复杂
合规数据本地化	Placement 策略限制资源只能分发到特定地域集群	策略变更后存量资源需手动迁移

避坑提醒： 联邦集群的 Host Cluster 本身也是一个 Kubernetes 集群，它的 etcd 和 API Server 必须做高可用部署。一旦 Host Cluster 宕机，所有联邦资源的变更操作将暂停，但已分发的成员集群仍可独立运行。

2.3 集群注册中心：去中心化的多集群管理

集群注册中心（Cluster Registry）是一种轻量级、去中心化的多集群管理模型。它不维护全局控制面，而是通过一个中央元数据存储（通常基于 etcd 或 CRD）记录每个集群的 API Server 地址、认证信息、容量状态和健康状态。Kubernetes 社区在 sig-multicluster 中推进的 Cluster API 和 Karmada 都采用了注册中心思想。

2.3.1 注册中心 vs 联邦集群

对比维度	联邦集群（KubeFed）	集群注册中心（Cluster Registry）
控制面模型	集中式 Host Cluster	去中心化，每个集群平等
资源同步	Push 模式，Host 主动分发	Pull 模式，成员集群主动拉取或事件驱动
故障影响	Host 故障导致管理面不可用	注册中心故障不影响已运行的工作负载
扩展性	成员集群数超过 50 后性能下降	支持数百集群，注册中心可水平扩展
典型实现	KubeFed v2	Karmada、Cluster API、Multi-Cluster Services API

2.3.2 集群注册中心的工作流程

集群注册：每个成员集群启动时，向注册中心写入 Cluster 对象，包含 API Server 端点、CA 证书、健康检查 URL。
心跳与状态同步：成员集群定期发送心跳（通常 10-30 秒），注册中心更新集群状态为 Ready / NotReady / Unknown。
资源调度决策：调度器（如 Karmada 的 scheduler）从注册中心读取所有集群的剩余容量、节点数量、地域标签，做出分发决策。
故障摘除：当注册中心连续 N 次未收到心跳，自动将集群标记为 Unreachable，停止向其分发新工作负载。

  生产实践： 注册中心本身建议使用独立的 etcd 集群或云厂商托管的 KV 存储（如 etcd + TLS）。不要将注册中心与业务集群的 etcd 复用，避免故障扩散。

2.4 多集群架构对比与选型

以下 SVG 图展示了联邦集群与集群注册中心两种模式的核心差异，帮助你在课程项目中做出架构选型。

2.5 多集群网络与身份互联

无论采用联邦集群还是注册中心模式，多集群之间的网络连通与身份信任都是基础设施前提。以下是三种常见的互联方案对比：

方案	网络模型	身份认证	延迟	运维复杂度
VPN / 专线	L3 隧道，所有集群在同一 VPC	IPSec / TLS 证书	低（<5ms 同区域）	中，需维护 VPN 网关
Service Mesh（Istio）	L7 代理，通过 Spire 做 SPIFFE 身份	mTLS + 工作负载身份	中（10-20ms 额外开销）	高，需部署控制面与 sidecar
Cluster Mesh（Cilium）	L3 Overlay，基于 eBPF 直接路由	Cluster Mesh 证书 + 节点身份	低（<3ms 同区域）	低，Cilium 原生支持

推荐组合： 对于本课程的多租户签名链路场景，建议使用 Cilium Cluster Mesh 作为网络互联方案，配合 Karmada 作为集群注册中心。这样既能获得低延迟的 Pod-to-Pod 通信，又能通过 Karmada 的 ResourceTemplate 实现跨集群的签名服务部署。

2.6 集群注册中心的健康检查与故障摘除

集群注册中心必须能够准确判断成员集群的健康状态，并在故障发生时快速摘除。以下是一个基于 Lease 机制的健康检查流程：

Lease 创建：每个成员集群在注册中心的 cluster-leases Namespace 下创建一个 Lease 对象，spec.holderIdentity 为集群 ID。
心跳更新：成员集群的 agent 每 15 秒更新 Lease 的 spec.renewTime 字段。
超时判定：注册中心的 controller 每 30 秒扫描所有 Lease，如果 now - renewTime > 60s，将集群状态置为 NotReady。
故障摘除：连续 3 次超时（即 180 秒无心跳），注册中心从调度候选列表中移除该集群，并触发告警。
自动恢复：当 agent 恢复心跳后，Lease 重新更新，controller 将集群状态置回 Ready，重新加入调度池。

# 示例：成员集群心跳 Lease 对象
apiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
  name: cluster-east-1
  namespace: cluster-leases
spec:
  holderIdentity: "cluster-east-1"
  leaseDurationSeconds: 60
  renewTime: "2025-03-21T10:30:00Z"

生产注意： 不要将心跳间隔与超时时间设置过短（例如 <10s），避免网络抖动导致频繁摘除。建议心跳间隔 = 15s，超时阈值 = 60s，摘除阈值 = 180s。同时为注册中心 controller 配置 熔断机制：如果连续摘除超过 30% 的集群，暂停摘除并触发人工介入。

2.7 本章小结

多集群架构解决了单集群在故障域、租户隔离、地域延迟和资源配额上的瓶颈。
联邦集群（KubeFed）提供集中控制面，适合 10-50 集群规模，但 Host Cluster 存在单点风险。
集群注册中心（Karmada / Cluster API）采用去中心化模型，支持 100+ 集群，故障影响更小。
网络互联推荐 Cilium Cluster Mesh，身份认证使用 mTLS 或 SPIFFE。
健康检查基于 Lease 机制，心跳间隔 15s、超时 60s、摘除 180s 是经过生产验证的参数。