3. 集群间网络连通性：PodCIDR 路由与 Overlay 网络、跨集群 Service 发现原理、ClusterMesh 的 DNS 解析机制

多集群网络连通性是 ClusterMesh 能够正常工作的基石。本章将深入剖析 Cilium 在跨集群场景下如何解决 Pod 网络互通、Service 发现以及 DNS 解析这三大核心问题。理解这些底层机制，是运维大规模多集群拓扑、设计租户边界隔离策略的前提。

3.1 PodCIDR 路由与 Overlay 网络模式

ClusterMesh 支持两种主要的跨集群网络连通模式：直接路由（Direct Routing）和 Overlay 网络（Overlay / VXLAN）。选择哪种模式取决于底层网络基础设施的能力。

特性 直接路由（Direct Routing） Overlay 网络（VXLAN）
网络要求 底层网络（如 AWS VPC、GCP VPC、物理路由器）必须支持路由表配置，且集群节点间 L3 可达。 底层网络仅需支持 IP 转发，无需感知 PodCIDR。通过 VXLAN 隧道封装跨集群流量。
PodCIDR 路由 每个集群的 PodCIDR 范围必须全局唯一，并通过 BGP 或云厂商 API 注入到底层网络路由表中。 PodCIDR 可以重叠（但通常不建议），因为流量被封装在节点 IP 的隧道中。
性能 接近原生网络性能，无额外封装开销。 存在 VXLAN 封装/解封装开销，通常性能损失在 5%-15% 之间。
运维复杂度 需要管理跨集群/跨云的路由表，变更风险较高。 运维简单，对底层网络透明，适合混合云或多云场景。
ClusterMesh 推荐 适用于同云厂商、同 VPC 或拥有 BGP 能力的数据中心。 适用于跨云、跨 VPC 或无法控制底层路由的环境。
生产建议： 在无法保证 PodCIDR 全局唯一或无法操作底层路由表时，优先选择 Overlay 模式。Cilium 的 VXLAN 实现经过深度优化，性能损失在可接受范围内。

3.1.1 跨集群 Pod 流量路径（Overlay 模式）

下图展示了在 Overlay 模式下，集群 A 中的一个 Pod 访问集群 B 中另一个 Pod 的完整数据流。核心在于 Cilium 代理如何通过隧道端点（Tunnel Endpoint）进行封装与转发。

ClusterMesh Overlay 模式跨集群 Pod 流量路径 集群 A (Cluster A) 集群 B (Cluster B) 节点 A-1 IP: 10.0.1.10 Pod A IP: 10.1.1.5 Cilium Agent 节点 B-1 IP: 10.0.2.20 Pod B IP: 10.2.2.10 Cilium Agent ① 原始包 VXLAN 隧道封装 ② 封装 ③ 外层 IP: 10.0.1.10 → 10.0.2.20 VXLAN 隧道解封装 ④ 解封装 ⑤ 原始包 关键点 Cilium Agent 作为隧道端点，负责封装/解封装。底层网络仅感知节点 IP 通信。
流量路径拆解：
  1. 原始包生成： Pod A (10.1.1.5) 向 Pod B (10.2.2.10) 发送数据包。
  2. 隧道封装： 节点 A-1 上的 Cilium Agent 识别目标 IP 属于远程集群，将原始数据包封装为 VXLAN 报文。外层源 IP 为节点 A-1 IP (10.0.1.10)，外层目标 IP 为节点 B-1 IP (10.0.2.20)。
  3. 网络传输： 封装后的报文通过底层网络（互联网或 VPC）路由到节点 B-1。
  4. 隧道解封装： 节点 B-1 上的 Cilium Agent 收到 VXLAN 报文，解封装还原出原始数据包。
  5. 本地转发： Cilium Agent 根据内部路由，将原始数据包转发给 Pod B。

3.2 跨集群 Service 发现原理

ClusterMesh 的核心能力之一是允许一个集群中的 Pod 通过 Service 名称访问另一个集群中的后端 Pod。这依赖于 Cilium 的 Service 导出（Service Export）和 Service 导入（Service Import）机制。

3.2.1 Service 导出与导入流程

当一个 Service 被标记为“全局”时，Cilium 会将其 Endpoint 信息同步到所有已加入 ClusterMesh 的集群中。这个过程是自动的，无需手动配置 DNS 或 Ingress。

ClusterMesh 跨集群 Service 发现流程 集群 A (消费者) Pod 消费者 curl service-b Cilium Agent 导入的 Service service-b ClusterIP: 10.3.0.1 后端: 10.2.2.10:80 (远程 Pod B) DNS 解析 流量转发 集群 B (提供者) Service B ClusterIP: 10.2.0.1 Pod B IP: 10.2.2.10:80 Cilium Agent ClusterMesh 控制面同步 (KVStore / gRPC) 导出 Endpoint 同步到消费者集群 核心：Cilium 在本地集群创建“影子 Service”，其 ClusterIP 和 Endpoint 指向远程 Pod。
关键概念： 消费者集群中的“导入的 Service”是一个本地虚拟对象。它拥有一个本地 ClusterIP，但后端 Endpoint 列表由远程集群的 Pod IP 组成。Cilium 的 eBPF 程序负责将发往该 ClusterIP 的流量通过 Overlay 或直接路由转发到远程 Pod。

3.2.2 Service 发现的关键组件

组件 角色 说明
CiliumClusterwideEnvoyConfig L7 策略与流量治理 用于跨集群的 HTTP/gRPC 流量管理，可配合 Service 导入实现灰度发布。
CiliumService Service 定义 Cilium 内部的 Service 表示，包含 ClusterIP、端口、后端 Endpoint 列表。
CiliumEndpoint Pod 级别的网络端点 包含 Pod 的 IP、安全标识、健康状态。跨集群同步时，CiliumEndpoint 是核心同步单元。
KVStore (etcd / consul) 控制面状态同步 用于在集群间同步 Service、Endpoint、Identity 等信息。是 ClusterMesh 的“大脑”。

3.3 ClusterMesh 的 DNS 解析机制

在多集群环境中，DNS 解析是 Service 发现的第一步。ClusterMesh 并没有引入一个全局 DNS 服务器，而是通过 CoreDNS 的插件机制和 Cilium Agent 的本地缓存来实现高效、低延迟的跨集群 DNS 解析。

3.3.1 解析流程

  1. Pod 发起 DNS 查询： Pod 中的应用程序向集群 DNS 服务器（通常是 CoreDNS）查询 service-b.ns-b.svc.cluster.local。
  2. CoreDNS 查询 Cilium 插件： CoreDNS 的 cilium 插件拦截该查询。该插件会向本地 Cilium Agent 发起 gRPC 调用，询问该 Service 是否存在。
  3. Cilium Agent 本地查找： Cilium Agent 维护着一个本地 DNS 缓存，该缓存通过 ClusterMesh 控制面同步了所有远程集群的 Service 信息。Agent 在缓存中查找 service-b。
  4. 返回本地 ClusterIP： 如果找到，Cilium Agent 返回该 Service 在本地集群的 ClusterIP（即导入的 Service 的 IP）。CoreDNS 将该 IP 返回给 Pod。
  5. Pod 发起连接： Pod 直接向该本地 ClusterIP 发起连接。后续的流量转发由 Cilium 的 eBPF 程序处理，将流量导向远程 Pod。
重要限制： 跨集群 DNS 解析返回的是本地 ClusterIP，而不是远程 Pod 的 IP。这意味着 Pod 看到的 Service IP 是本地集群的虚拟 IP，这有助于保持网络策略和监控的一致性。但是，这也意味着传统的 headless service 在跨集群场景下需要特殊处理，因为 headless service 期望返回 Pod IP 列表。

3.3.2 DNS 解析性能优化

为了减少跨集群 DNS 查询的延迟，ClusterMesh 采用了多层缓存和预同步策略：

优化手段 描述 效果
Cilium Agent 本地缓存 每个节点上的 Cilium Agent 维护一个完整的远程 Service 和 Endpoint 列表。 DNS 查询无需跨集群网络，延迟通常在微秒级。
KVStore 事件驱动更新 当远程集群的 Service 或 Endpoint 发生变化时，KVStore 会推送事件，Cilium Agent 实时更新本地缓存。 缓存几乎实时同步，TTL 可以设置得很短（如 5 秒），减少 DNS 缓存污染。
CoreDNS 插件级联 CoreDNS 的 cilium 插件会优先查询本地 Agent，失败后才回退到上游 DNS。 避免不必要的跨集群 DNS 递归查询。
运维检查点：
  • 使用 cilium service list 命令查看本地节点上导入的远程 Service 列表。
  • 使用 cilium endpoint list 查看跨集群 Endpoint 的健康状态。
  • 检查 CoreDNS 日志，确认 cilium 插件是否正常工作：kubectl logs -n kube-system -l k8s-app=kube-dns。

3.3.3 跨集群 DNS 解析的故障排查思路

当跨集群 Service 无法通过 DNS 名称访问时，可以按照以下步骤进行排查：

  1. 验证 ClusterMesh 状态： 使用 cilium clustermesh status 确认集群间连接正常，KVStore 同步无延迟。
  2. 检查 Service 导出： 在提供者集群中，确认 Service 已正确标记为全局：kubectl get service service-b -o yaml | grep global。
  3. 检查 Service 导入： 在消费者集群中，确认已创建对应的导入 Service：kubectl get service service-b -n ns-b。
  4. 测试 DNS 解析： 在消费者集群的 Pod 中，使用 nslookup service-b.ns-b.svc.cluster.local 或 dig 命令，确认返回的 IP 是本地 ClusterIP。
  5. 检查 Cilium Agent 缓存： 在消费者集群的节点上，使用 cilium service list | grep service-b 确认本地缓存中存在该 Service 及其后端 Endpoint。
常见问题： 如果 DNS 解析成功但连接失败，通常是因为网络策略（NetworkPolicy）或 CiliumNetworkPolicy 阻止了跨集群流量。检查 cilium endpoint list 中相关 Endpoint 的“Ingress/Egress”状态是否为“Denied”。
← 上一章 📖 返回目录 下一章 →