3. ClusterMesh 架构解析：控制面组件、数据面组件、全局负载均衡器、跨集群证书管理
ClusterMesh 是 Cilium 提供的多集群互联方案，其架构设计遵循“控制面与数据面分离”的云原生原则。控制面负责服务发现、身份同步与证书签发；数据面通过轻量级隧道或直接路由完成跨集群流量转发；全局负载均衡器基于 eBPF 实现跨集群服务权重调度；证书管理则依赖自建 CA 与 SPIRE 集成，保障 mTLS 通信。
3.1 控制面组件
控制面组件运行在管理集群或每个集群的 kube-system 命名空间中，主要包含以下核心进程：
| 组件 | 部署形态 | 核心职责 |
|---|---|---|
| ClusterMesh APIServer | Deployment（1~3 副本） | 暴露跨集群服务发现接口，同步 EndpointSlice 与 Identity |
| KVStore Mesh | etcd 集群 / 外部 KV | 存储跨集群共享的 Service、Node、Identity 元数据 |
| cilium-operator | Deployment（1 副本） | 管理跨集群 Service 的 DNS 记录、负载均衡策略 |
| SPIRE Server | StatefulSet（1~3 副本） | 签发跨集群工作负载证书，维护 SPIFFE 身份注册 |
关键设计：ClusterMesh 不要求所有集群共享同一个 etcd，而是通过 KVStore Mesh 层做逻辑聚合，每个集群只同步自己需要的 Service 和 Identity，避免全局广播风暴。
3.2 数据面组件
数据面组件运行在每个集群的每个节点上，以 DaemonSet 形式部署，负责实际的跨集群包处理：
- cilium-agent：通过 eBPF 程序在节点网络栈中注入跨集群转发规则，支持 VXLAN、Geneve 或直接路由封装。
- cilium-health-ep：跨集群健康检查代理，定期探测对端集群的节点可达性与延迟。
- Envoy 代理（可选）：当启用 L7 策略时，Envoy 作为 Sidecar 处理跨集群 HTTP/gRPC 流量。
数据面转发路径遵循“源集群节点 → 隧道/VXLAN → 目标集群节点 → 目标 Pod”的模型，所有包在 eBPF 层面完成封装与解封装，无需 iptables 或用户态代理。
3.3 全局负载均衡器
ClusterMesh 的全局负载均衡器（Global Load Balancer）并非独立组件，而是由 cilium-agent 中的 eBPF 程序与 cilium-operator 中的服务控制器共同实现。其核心机制如下：
- 服务导出：通过
kind: CiliumServiceExport将集群内 Service 标记为跨集群可访问。 - 权重分配：每个集群的
cilium-operator根据本地节点健康状态、CPU 负载、网络延迟动态计算权重。 - eBPF 调度：源集群的
cilium-agent在 BPF 程序中维护一个全局后端表，按权重轮询或最小连接数选择目标集群的 Pod。 - 会话保持：支持基于源 IP 或 L4 端点的会话亲和性，确保同一客户端请求路由到同一后端。
| 调度策略 | eBPF 实现方式 | 适用场景 |
|---|---|---|
| 权重轮询 | BPF_MAP_TYPE_ARRAY 存储权重，BPF 程序自增索引 | 通用负载均衡 |
| 最小连接数 | BPF_MAP_TYPE_PERCPU_HASH 跟踪活跃连接数 | 长连接服务 |
| 地理位置亲和 | 基于节点标签与集群 ID 的哈希选择 | 边缘计算、多区域部署 |
性能优势：全局负载均衡器完全运行在 eBPF 内核态，无需用户态代理参与，单节点可支撑百万级并发跨集群连接，延迟增加小于 50μs。
3.4 跨集群证书管理
ClusterMesh 使用 SPIRE (SPIFFE Runtime Environment) 作为跨集群身份与证书管理基础设施。每个集群运行一个 SPIRE Server，通过联邦机制建立信任关系。
证书签发流程
- 工作负载注册：Pod 启动时，SPIRE Agent 通过 k8s 工作负载注册器获取 Pod 的 ServiceAccount 与命名空间。
- CSR 请求：SPIRE Agent 代表 Pod 向本集群 SPIRE Server 发起证书签名请求（CSR），请求中包含 SPIFFE ID（如
spiffe://cluster-a/ns/default/sa/my-sa）。 - 联邦验证：如果目标服务在另一个集群，SPIRE Server 通过联邦 API 向对端集群的 SPIRE Server 验证 SPIFFE ID 的合法性。
- 证书下发：验证通过后，SPIRE Server 签发短期 X.509 证书（默认 TTL 24 小时），通过 SPIRE Agent 下发到 Pod 的 Sidecar 或 cilium-agent。
- mTLS 握手：跨集群通信时，双方使用下发的证书进行双向 TLS 验证，cilium-agent 在 eBPF 层面检查证书中的 SPIFFE ID 是否匹配网络策略。
证书轮换与吊销
- 自动轮换：SPIRE Agent 在证书过期前（默认 TTL 的 50%）自动发起新 CSR，旧证书在轮换完成后立即失效。
- 吊销列表：SPIRE Server 维护 CRL（证书吊销列表），当 Pod 被删除或 ServiceAccount 被修改时，对应证书被加入 CRL。
- 联邦信任更新：每个集群的 SPIRE Server 定期通过 bundle 端点交换根 CA 与 CRL，确保吊销信息跨集群传播延迟小于 30 秒。
安全注意事项：跨集群证书管理依赖 SPIRE 联邦的初始信任引导。首次部署时，必须通过安全渠道（如 Kubernetes Secret 或 Vault）交换各集群的根 CA 证书。禁止使用 HTTP 明文传输 bundle 信息。
3.5 架构总结
| 层级 | 核心组件 | 通信协议 | 安全机制 |
|---|---|---|---|
| 控制面 | ClusterMesh APIServer、KVStore Mesh、SPIRE Server | gRPC（双向流）、etcd gRPC | mTLS、SPIFFE 身份验证 |
| 数据面 | cilium-agent、Envoy、health-ep | VXLAN/Geneve、eBPF 直接路由 | X.509 证书、eBPF 策略执行 |
| 全局负载均衡 | cilium-operator + eBPF 后端表 | BPF 内核态调度 | 权重动态调整、会话保持 |
| 证书管理 | SPIRE Server/Agent、联邦 API | SPIFFE 联邦、HTTPS bundle 交换 | 短期证书、CRL、自动轮换 |
理解 ClusterMesh 的四层架构是后续配置多集群网络策略、审计门禁与变更门禁的基础。控制面保证身份与策略的一致性，数据面保证转发的性能与安全，全局负载均衡器提供跨集群流量调度能力，证书管理则确保所有通信都经过加密与身份验证。