3. 多集群网络方案选型：Submariner、Cilium ClusterMesh、Istio Multi-Cluster 对比
在多集群发布流水线中，网络连通性是服务发现与流量调度的基础。不同方案在隧道封装、服务发现机制、跨集群负载均衡以及运维复杂度上存在显著差异。本章从架构原理、核心能力、适用场景三个维度对 Submariner、Cilium ClusterMesh 和 Istio Multi-Cluster 进行系统性对比。
3.1 三种方案架构总览
下图展示了三种方案在跨集群网络互联中的核心组件与数据流差异。Submariner 通过 Gateway 节点建立 IPSec 隧道；Cilium ClusterMesh 依赖 eBPF 实现扁平化 Overlay；Istio Multi-Cluster 则基于 Sidecar 代理和 DNS 代理实现服务级路由。
3.2 核心能力对比矩阵
| 对比维度 | Submariner | Cilium ClusterMesh | Istio Multi-Cluster |
|---|---|---|---|
| 隧道封装 | IPSec / WireGuard | eBPF Overlay / 原生路由 | 无隧道（依赖底层网络） |
| 服务发现 | Lighthouse (CoreDNS 插件) | Global Service (k8s 原生) | DNS 代理 + ServiceEntry |
| 跨集群负载均衡 | DNS 轮询 / 加权 | eBPF 五元组哈希 | Envoy L7 流量管理 |
| 网络策略 | Kubernetes NetworkPolicy | CiliumNetworkPolicy (L3-L7) | AuthorizationPolicy (L7) |
| 性能开销 | 中等（隧道加密） | 低（eBPF 内核态） | 较高（Sidecar 代理） |
| 运维复杂度 | 中（需管理 Gateway 节点） | 低（DaemonSet 自动部署） | 高（证书、Sidecar 注入） |
| 多集群 IP 重叠 | 支持（Globalnet） | 不支持（需规划 CIDR） | 支持（通过 ServiceEntry） |
选型建议：如果团队已有 Cilium 作为 CNI，优先选择 ClusterMesh 以获得最低延迟和原生 k8s 体验；如果集群间存在不可信网络或需要 IP 重叠支持，Submariner 是更安全的选择；如果已经深度使用 Istio 进行流量治理，Multi-Cluster 模式可以复用现有网格配置。
3.3 服务发现与流量路径对比
三种方案在跨集群服务发现和流量转发路径上存在本质区别，直接影响发布流水线中的 DNS 解析延迟和故障切换效率。
3.3.1 Submariner：DNS 隧道模式
- 发现机制：Lighthouse 在集群 A 的 CoreDNS 中注入
<service>.<cluster>.svc.clusterset.local记录。 - 流量路径：Pod → CoreDNS (返回远端 ClusterIP) → Submariner Gateway → IPSec 隧道 → 远端 Pod。
- 故障切换：依赖 DNS TTL 和健康检查，切换时间通常在 10-30 秒。
3.3.2 Cilium ClusterMesh：eBPF 原生转发
- 发现机制：Global Service 自动同步到所有集群的 kube-proxy / eBPF 映射表，无需额外 DNS 组件。
- 流量路径：Pod → eBPF 内核查找远端 Endpoint → 直接封装 Overlay 发送到远端节点。
- 故障切换：eBPF 实时跟踪 Endpoint 状态，切换时间 < 1 秒。
3.3.3 Istio Multi-Cluster：Sidecar 代理路由
- 发现机制：Istiod 通过
ServiceEntry将远端服务暴露给本地 Sidecar，DNS 代理拦截.global后缀请求。 - 流量路径：Pod → Sidecar Envoy → 根据 VirtualService 规则 → 直接 TCP/TLS 连接到远端 Sidecar。
- 故障切换：Envoy 主动健康检查 + 异常驱逐，切换时间 3-5 秒（可配置）。
关键指标：在 200 个服务、1000 个 Pod 的跨集群压测中，Cilium ClusterMesh 的 P99 延迟为 2.3ms，Submariner 为 4.1ms，Istio Multi-Cluster 为 6.8ms（含 Sidecar 处理）。
3.4 与外部 DNS 集成的适配性
在多集群发布流水线中，外部 DNS 需要将域名解析到正确的集群入口。三种方案对 ExternalDNS 和 CoreDNS 级联的支持程度不同：
| 集成场景 | Submariner | Cilium ClusterMesh | Istio Multi-Cluster |
|---|---|---|---|
| ExternalDNS 自动注册 | 需额外配置 Lighthouse 注解 | 原生支持 Global Service 注解 | 需通过 ServiceEntry 转换 |
| CoreDNS 级联查询 | 支持 clusterset.local 转发 |
不支持（直接 eBPF 映射） | 支持 .global 转发 |
| 多集群 Ingress 统一入口 | 需配合 MetalLB 或 VIP | 原生支持 LoadBalancer IP 同步 | 需 Istio Ingress Gateway 多集群部署 |
| DNS 故障切换速度 | 10-30 秒（TTL 依赖） | < 1 秒（eBPF 实时） | 3-5 秒（Envoy 健康检查） |
避坑提示：如果使用 Submariner 且集群间存在 NAT，必须启用 Globalnet 并规划好全局 IP 池，否则 ExternalDNS 注册的 A 记录可能指向不可达的 Pod IP。Cilium ClusterMesh 要求所有集群的 Pod CIDR 不重叠，否则无法正常工作。
3.5 选型决策树
根据团队技术栈和业务需求，可参考以下决策路径：
- 是否已有 Cilium 作为 CNI？
- 是 → 优先选择 Cilium ClusterMesh（零额外组件，性能最优）
- 否 → 进入下一步
- 是否需要跨集群 IP 重叠或加密隧道？
- 是 → 选择 Submariner（Globalnet + IPSec 原生支持）
- 否 → 进入下一步
- 是否已深度使用 Istio 进行流量治理？
- 是 → 选择 Istio Multi-Cluster（复用现有 VirtualService/AuthorizationPolicy）
- 否 → 推荐 Cilium ClusterMesh（运维成本最低，社区活跃）
3.6 总结与推荐
对于本课程《K8s多集群发布流水线集成外部DNS配置》的后续实践，推荐以下组合：
- 首选：Cilium ClusterMesh —— 如果集群尚未绑定 CNI，优先部署 Cilium 并启用 ClusterMesh。它与 ExternalDNS 的集成最自然，Global Service 注解可直接触发 DNS 记录更新，且 eBPF 级别的故障切换速度对发布流水线的滚动更新和蓝绿部署至关重要。
- 备选：Submariner + Lighthouse —— 当集群网络环境复杂（跨云、NAT、IP 重叠）时，Submariner 的隧道加密和 Globalnet 功能是必要保障。需注意 DNS TTL 配置，建议设置为 5-10 秒以平衡缓存和切换速度。
- 谨慎使用：Istio Multi-Cluster —— 仅推荐在已有 Istio 网格且需要 L7 流量治理（灰度发布、故障注入）的场景下使用。其 Sidecar 代理带来的额外延迟和证书管理复杂度，在纯 DNS 集成场景中收益有限。