Cilium + EVPN Fabric: Cisco 客户案例

bobz965
85 阅读25分钟

下面我整理一版 Cilium + VXLAN/EVPN Fabric 实现“租户对应 VNI／VPC 隔离”的方案思路，包括背景、关键组件、流程、优缺点、落地注意事项。你可据此判断当前是否适合你场景，以及哪些地方需要进一步补充或定制。

背景

  • 在数据中心（或私有云）网络架构中，若希望像公有云一样给每个租户（Tenant）或业务单元提供 “私有 VPC” 样式隔离网络”——即每个租户拥有自己的 overlay 隧道（通常为 VXLAN）映射到一个 VNI（VXLAN Network Identifier）／VRF，再在二层／三层上与其他租户隔离。
  • EVPN（Multiprotocol BGP EVPN）是业界用于 VXLAN overlay 网络的控制平面标准，能够支持多租户、桥接＋路由、MAC/IP 广播／ARP 抑制、VNI 划分、VRF 隔离等。 (Cisco)
  • Cilium 本身是 Kubernetes CNI + eBPF 平台，提供 overlay（如 VXLAN／Geneve）、网络策略、安全、可观测性等能力。 (docs.cilium.io)
  • 因此，将 Cilium 与下层的 EVPN/VXLAN Fabric（例如用 Cisco Nexus 或其他交换器做 EVPN VTEP）结合起来，可以在 Kubernetes 侧编排、控制 Pod/Namespace/服务的网络，而在物理交换网络侧借助 EVPN Fabric 实现租户级 VNI／VRF 隔离、东-西／北-南流量接入、物理／虚拟设备融合等。

关键组件 & 技术关系

下面列出方案中常涉及的组件及它们之间的关系：

  • Cilium 节点（Kubernetes worker、或 CNI Agent 所在节点）

    • 配置为使用 VXLAN 隧道（或 Geneve），节点之间 Pod→Pod 通常封装。Cilium 的 “Routing – Encapsulation” 文档描述了节点间 VXLAN 隧道模式。 (docs.cilium.io)
    • 启用 VTEP Integration（beta 特性）——允许第三方 VTEP 设备（物理或虚拟）通过 VXLAN 与 Cilium 管理的 Pod 通信。文档中指出 “VXLAN network identifier (VNI) must be configured as VNI 2” 在该功能中。 (docs.cilium.io)

  • 物理／虚拟 VTEP（VXLAN Tunnel Endpoint）设备，例如交换机或路由器作为 EVPN Fabric 的一部分

    • 支持 MP-BGP EVPN 控制面，将 VNI／VRF／MAC-IP 等信息通告给互联 VTEP 节点。 (Cisco)
    • 每个 Tenant 可映射为一个 VNI (Layer 2) 或 L3VNI (Layer 3)＋VRF。比如 Cisco 文档中提 “VXLAN network identifiers (VNIs) define the Layer-2 domains and enforce Layer-2 segmentation … Layer-3 segmentation among VXLAN tenants is achieved by … separate Layer-3 VNI mapped to each VRF instance.” (Cisco)

  • 路由／控制平面（BGP/EVPN）

    • Cilium 支持 BGP 控制平面资源（如 CiliumBGPClusterConfig、CiliumBGPPeerConfig、CiliumBGPAdvertisement）可将 Pod 网络或服务前缀通告给外部路由器／Fabric。 (docs.cilium.io)
    • 在 EVPN Fabric 侧，通过 MP-BGP EVPN 的 NLRI （MAC/IP 前缀、路由区分符、路由目标）实现租户隔离、多租户网络。 (Cisco)

实现流程（方案性）

以下是一个典型 “租户 → VNI” 的实现流程思路：

  1. 租户网络规划

    • 定义每个租户一个 VNI （例如 VNI 10010、10020、…），对应一个 VRF 或 overlay 网络。
    • 在 EVPN Fabric 设备上为每个 VNI 做 L2（或 L3）域配置，并映射到对应 VRF。参考文档中 “vPC VXLAN EVPN Leaf and Spine – L3VNI configuration – Multi Tenant” 的例子。 (Nick Carlton)

  2. Fabric 侧配置

    • 在 Leaf/Spine 交换设备（或 VTEP）上配置 NVE (Network Virtualization Edge) 接口，成员 VNI 10010 、10020 等。 例如：

      interface nve1
  member vni 100010
    suppress-arp
  member vni 100020
    suppress-arp
evpn
  vni 100010 l2
    rd auto
    route-target import auto
    route-target export auto
  vni 100020 l2
    rd auto
    route-target import auto
    route-target export auto

      （摘自博客例子） (Nick Carlton)

    • 配置 VRF ／L3VNI 以实现租户间三层隔离。

  3. Cilium 节点／Kubernetes 侧配置

    • 启用 Cilium 的 VTEP integration 功能，让 Cilium 节点能够作为 VXLAN 隧道端点或与 VTEP 设备互通。文档说明该功能“允许第三方 VTEP 设备通过 VXLAN 与 Cilium‐managed Pods 通信”。 (docs.cilium.io)
    • 配置 Cilium 的 BGP 控制平面（如果需要外部路由通告）以将 Pod 网络／服务前缀传递给 Fabric。 (docs.cilium.io)

  4. 租户 流量隔离／映射

    • 将 Kubernetes 中不同租户（如 Namespace 或 标签）映射至不同 VNI。具体做法可能包括：

      • 在 Cilium 中打标签或身份（Identity）区分租户。
      • 在 Fabric 端 VNI 映射时，仅将 Kubernetes 节点（或其 VTEP 接口）加入相应 VNI 组。

    • 对于流量进入/离开租户网络（北-南／东-西），Fabric 通过 EVPN 控制平面实现租户隔离（不同 VNI 不互通），除非做 路由 leak 或 VRF 交互。

  5. 集成验证

    • 在 Cilium 节点上测试 VXLAN 隧道、Pod 与外部设备通信。Cilium 文档中显示了如何创建 vxlan2 设备并走 VXLAN 隧道到 VTEP。 (docs.cilium.io)
    • 在 Fabric 设备上验证 EVPN 路由表、VNI 成员、MAC/IP NLRI 等。

  6. 运维／策略

    • 每个租户 VNI 可设置不同 Subnet、不同 NetworkPolicy、安全策略。

    • Fabric 可基于 BGP Community、Route-Target 等做路由过滤、租户隔离。博客中提到：

      “Cilium will add BGP community of 64512:301 to any advertisements of pods belonging to Tenant1 … Pod2 will be advertised with a different community such as 64512:302.” (思科社区)

    • 安全、可见性、计费、租户生命周期管理等也可以在这个架构中实现。

图示（示意）

Image

Image

Image

Image

Image

Image

优点与适用场景

优点

  • 提供了物理网络侧和 Kubernetes 网络侧端到端的租户隔离能力（overlay + Fabric 融合）。
  • 租户网络能够用标准 EVPN/VXLAN 技术进行隔离（成熟、可扩展）→ 支持大规模多租户。
  • Kubernetes 侧使用 Cilium 提供细粒度网络策略、安全、可观察性。
  • 可结合物理或虚拟网络设备（VTEP）实现混合环境（VM、裸机、容器）。
    适用场景
  • 私有云 / 企业数据中心希望提供 “类似 AWS VPC” 的租户网络隔离。
  • 多租户 Kubernetes 环境，需网络隔离、物理网络整合、overlay 与 underlay 协作。
  • 存在物理交换／EVPN Fabric 已建或计划建设。

限制／注意事项

  • Cilium 的 VTEP integration 功能目前为 beta 状态。 (docs.cilium.io)
  • 文档中指出：目前该集成功能中的 VNI 固定为 “2” 用于 VTEP 整合场景。也就是说，Cilium 默认并未提供 “每个租户一个可指定 VNI” 的灵活映射。 (docs.cilium.io)
  • 将 Kubernetes-Namespace/租户 映射到 Fabric VNI 这一逻辑，需要额外的设计和实现（可能需定制脚本或工具）。
  • Fabric 侧配置比较复杂（VNI / VRF /Route-Target/RD 等）。例如 EVPN 设计指南中提及的细节。 (Cisco)
  • 多租户规模如果非常大（数千租户）可能在 EVPN 路由量、MAC/IP 表收敛方面有挑战。 (Reddit)

在你场景中需要考虑的关键点

如果你打算在你的 Kubernetes 环境／数据中心落地此方案，建议重点考虑以下：

  • 租户维度网络规划：每租户的 VNI 号、Subnet 范围、是否需要 L2 还是 L3 overlay。
  • Cilium 部署模式：是否启用 VTEP integration、是否使用 Cilium 的 BGP 控制平面功能。
  • Fabric 设备支持情况：是否已有 EVPN/VXLAN Fabric、交换机是否支持所需 NVE 配置、VNI 映射、VRF。
  • 租户映射机制：如何从 Kubernetes 侧将租户（Namespace/标签）与对应 VNI 进行绑定。
  • 策略与安全：租户隔离、访问控制、北-南／跨租户流量如何管理。
  • 运营与可观测性：如何监控 VNI 状态、流量、分区、故障隔离。
  • 测试和迁移：搭建概念验证环境、验证租户隔离、故障恢复、扩展性。

如果你愿意，我可以 帮你查找一个“Cilium + Cisco Nexus EVPN Fabric”落地案例（白皮书、演讲、配置范例）并整理一个更具实操性的配置模板。你要吗？

找到几篇关于 Cilium 与 Cisco ／ Nexus 9000 Series EVPN Fabric 集成、租户隔离（VPC、VRF、VNI）相关的案例和文档，下面整理给你 ——虽然并非每个都完全涵盖 “租户→VNI 对应” 的细节，但可作为落地参考。你可以基于这些来进一步定制方案。

✅ 查到的关键案例／文档

  1. “Cilium with N9K EVPN Fabric with different Tenants Access”
    来自 Cisco 社区一篇帖子：《Cilium with N9K EVPN Fabric with different Tenants Access (Data Center & Cloud Knowledge Base)》. (思科社区)

    • 文中展示了 Cilium 与 Nexus EVPN Fabric 不同租户接入的思路。
    • 提到通过 BGP community（例如 64512:301, 64512:302）为不同租户的 Pod 广告流量区分。 (思科社区)
    • 虽然未细到 “每个租户一个 VNI 指定” 的配置示例，但确实说明了租户隔离／访问控制在这种架构下是可行的。
    • 所以这是一个非常有价值的 落地参考。

  2. Cisco Live 2025 演讲文档：BRKDCN-2982 “Architecting Private Cloud Networking & Services with Cisco Nexus and Cilium Enterprise”
    PDF 文档可查看：BRKDCN-2982. (ciscolive.com)

    • 本演讲目标之一：如何用 Nexus Fabric + Cilium 来打造 “VPC-like 服务” 在私有云环境中。 (ciscolive.com)
    • 内容包括：Nexus Fabric 设计（Overlay & Underlay, EVPN/VXLAN）＋Cilium 网络／安全能力。 (ciscolive.com)
    • 所以这是一个 高层架构级别 的参考，适合把握整体思路。

  3. “Cisco N9K EVPN Fabric with Kubernetes in multiple VRF/tenant”
    来自 Cisco 社区博客帖：Cisco N9K EVPN Fabric with Kubernetes in multiple VRF tenant. (思科社区)

    • 提及 多租户 VRF + Kubernetes 集群 在 Nexus EVPN Fabric 中的实现。
    • 虽然文章标题中没有明确提“Cilium”，但内容跟多租户隔离＋VRF／VNI 相关，很值得参考。

  4. Cilium 官方文档：VXLAN Tunnel Endpoint (VTEP) Integration (beta)
    官方说明：Cilium 支持 VTEP 集成，可让第三方 VTEP 设备通过 VXLAN 与 Cilium 托管的 Pods 通信。 (docs.cilium.io)

    • 文档中明确指出：“The VXLAN network identifier (VNI) must be configured as VNI 2, which represents traffic from the VTEP as the world identity.” (docs.cilium.io)
    • 说明了虽然支持 VTEP，但目前 VNI 是固定为 2，即尚未提供灵活 “租户指定 VNI” 的选项。

🔍 从这些参考中得出的洞察 &建议

  • 虽然有多篇文档／案例说明 Cilium + Nexus EVPN Fabric 可以实现 “租户访问隔离／多租户 VRF” 的能力，但 尚未找到公开文档 明确展示 “为每个租户在 Fabric 中分配一个不同 VNI，并且在 Cilium CRD 中指定该 VNI” 的完整流程。

  • Cilium 的 VTEP 集成功能目前为 beta，并且文档指出 VNI 被固定为 2。意味着如果你想为每个租户有不同 VNI／真正“VPC 风格”隔离，可能 需要自行扩展／定制 这部分功能。

  • 落地时建议你结合以下做法：

    • 在 Fabric 侧：为每个租户预定义 VNI／VRF，并在 Nexus／Leaf-Spine 设备上配置 NVE 接口成员、EVPN 路由目标 (Route-Target)、RD 等。
    • 在 Kubernetes + Cilium 侧：目前可能通过标签／Namespace／Identity 将租户区分，再通过路由通告 (BGP)＋社区 (community) 机制与 Fabric 侧绑定。即：Fabric 用 community/RT 来识别租户，Cilium 将 Pod 网络通告时加上租户-特定 community。
    • 如需“租户指定 VNI”，你可能要开发或选择 Cilium Enterprise 版本中更高级的租户分段功能，或与 Cisco／Isovalent 合作了解是否有企业特性支持。

  • 此外，建议你联系 Cisco 或 Isovalent 获取该演讲文档的完整 PPT +配置示例，因为演讲资料中可能隐藏了更多具体的配置范例（例如 Nexus CLI、Cilium Helm 设置、BGP community 实例等）。

如果你愿意，我可以 帮你查找具体到 Nexus CLI 配置 + Cilium Helm 值 + BGP 社区绑定 + VNI 映射脚本 的开源或白皮书级别范例（可能需要登录厂商站点）并整理成一个文档。你看要吗？

是的，在 Cilium 与 EVPN Fabric 结合的场景中，通常更推荐使用 VXLAN 模式，而不是 Geneve 模式。原因主要在于 EVPN Fabric 生态和协议标准的兼容性。下面详细说明：

一、EVPN Fabric 原生设计基于 VXLAN

对比项VXLANGeneve
标准支持EVPN（RFC 7432）扩展专为 VXLAN 设计，广泛用于 DC Fabric 和 Spine-Leaf 架构Geneve 主要用于云虚拟化（如 OVS 、NSX），EVPN 标准中暂无成熟 Geneve 控制平面
交换机兼容性Cisco Nexus 、Arista 、Juniper 、Huawei 等主流 DC 交换机默认支持 VXLAN VNI/VRF 模型仅部分软件 VTEP 或 云虚拟交换机支持（OVS 、Linux Kernel）
控制平面MP-BGP EVPN 直接携带 VNI、MAC/IP、RT/RD 信息Geneve 没有 EVPN 原生字段定义，需自定义扩展
运维生态有成熟的 NVE 接口、CLI 模板、VNI-VRF 绑定方式缺乏成熟的硬件端运维体系

结论：EVPN Fabric = EVPN (BGP control plane) + VXLAN (overlay data plane)。
Geneve 暂不属于该标准控制平面体系。

二、Cilium 的 VXLAN 模式更容易与 Fabric 对接

Cilium 支持 tunnelProtocol: vxlan 与 tunnelProtocol: geneve 两种封装方式。

  • 在 VXLAN 模式下，Cilium 节点之间的 Overlay 隧道使用 标准 UDP 4789 端口，与 EVPN Fabric 中 NVE 接口完全一致。

  • 这样，Fabric 设备可直接视 Cilium 节点为 VTEP （VXLAN Tunnel Endpoint），并通过 VNI 实现 L2/L3 域隔离。

  • Cilium 官方 VTEP integration 功能也是基于 VXLAN 封装实现的，并明确要求 “VXLAN VNI = 2”。

    “The VXLAN network identifier (VNI) must be configured as VNI 2.” — docs.cilium.io VTEP integration

三、Geneve 模式的适用性

Geneve 的优点是支持扩展字段（Option TLV），在云虚拟化（如 OpenStack、NSX）或 SR-IOV 场景可携带更多上下文信息。但：

  • 硬件 EVPN 交换机普遍不支持 Geneve 封装。
  • 即使 Fabric 设备能理解 Geneve，也无法通过 EVPN 控制平面通告 Geneve 隧道。
  • 若 Cilium 使用 Geneve 模式，则需额外做 VTEP 网关或 overlay 转换层（如 OVS-VXLAN Bridge to Geneve），增加复杂度。

四、最佳实践建议

场景建议隧道模式原因
与 Cisco / Arista / Juniper EVPN Fabric 对接✅ VXLAN控制面原生支持，易对齐 VNI/VRF 映射
纯软件环境（无 Fabric）+ 需扩展字段⚙️ Geneve 可选可携带 eBPF metadata 等
混合环境（部分节点直连 EVPN Fabric）✅ VXLAN 优先减少封装转换，方便 BGP 通告
想实现 “VPC 对应 VNI”✅ VXLAN物理 Fabric 标准化 VNI 模型仅基于 VXLAN

五、总结一句话

如果目标是让 Cilium 集群融入 EVPN Fabric （如 Nexus 9000 系列）并实现 VPC/VNI 租户隔离，那么必须使用 VXLAN 模式。
Geneve 主要适合纯虚拟化或未来云原生数据平面场景，目前与 EVPN 不兼容。

是否希望我帮你画一张简图（对比 VXLAN vs Geneve 在 Cilium + EVPN Fabric 架构中的位置与数据流）？这能直观看出为什么 VXLAN 更合适。

查了一下，关于 OVN‑Kubernetes 与 OpenShift User Defined Networks (UDN)／OVN‑BGP Agent + EVPN 在 Red Hat OpenShift 中的关联，下面是整理出的要点 +当前支持状况。

✅ 支持情况 & 关键文档

  • 在 OpenShift 4.18 的博客中，Red Hat 提到 UDN（User Defined Networks）已从技术预览升级为 GA，并且 “built directly into OVN-Kubernetes is full support for Border Gateway Protocol (BGP) as a routing protocol for UDN pod and VM addressability and VPN support”. (红帽)

  • 同一篇文档还提到 “In the future, we plan to extend BGP support with Ethernet VPN (EVPN), allowing for the extension of a UDN segment into another OpenShift or a provider network.” (红帽)

  • 另一篇文章 “How to deploy EVPN in OpenStack Services on OpenShift” 描述了在 Red Hat OpenStack Services on OpenShift 环境中，在 OVN 环境里通过 ovn-bgp-agent 实现 EVPN。文章指出：

    “In Open Virtual Network (OVN) environments, ovn-bgp-agent … uses FRR to expose the routes … via EVPN … For every provider network … the provider network has been configured … with at least a Virtual Network Interface (VNI), and the VPN type is set to l3.” (Red Hat Developer)
    这说明在 OpenShift + OpenStack 混合场景中，OVN 的 BGP/EVPN 集成已有进展。

  • 关于 OVN-Kubernetes 插件，微软 Azure 页面说明 OVN-Kubernetes 是 OpenShift 的默认 CNI（在新的 Azure Red Hat OpenShift 集群中）且它使用 Geneve 隧道协议。 (Microsoft Learn)

⚠️ 关联关系 &限制

  • OVN-Kubernetes 与 OpenShift 网络：OpenShift 采用 OVN-Kubernetes 作为 CNI 插件（尤其在 4.x 版本）来替代旧的 SDN。 OVN-Kubernetes 本身实现了 overlay 网络、网络策略、分布式路由等。 (DevOps.dev)
  • UDN 为 OpenShift 提供了 “自定义网络分段”能力（例如自定义 L2、L3、localnet 段）并且与 OVN-Kubernetes 集成。UDN 文档中说明它“支持 BGP 作为路由协议 … VPN 支持”，并规划将“EVPN 扩展”纳入未来功能。 (红帽)
  • 在当前公开资料中，虽然提及 “未来将扩展 BGP 支持 EVPN”，但尚未确认 OpenShift 的正式版本中已经全面支持 “EVPN (L2 domain stretch + VNI mapping)” 与物理网络 Fabric 深度集成。也就是说，EVPN 功能仍然是未来方向，而非完全 GA 在所有场景。
  • OVN-Kubernetes 默认使用 Geneve 协议作为 overlay 隧道（至少从 Azure Red Hat OpenShift 的文档来看）而不是 VXLAN。 (Microsoft Learn) 这意味着如果你希望通过 VNI/VXLAN 模式实现 EVPN Fabric 集成，可能还需要额外配置或定制。
  • 在 OpenStack + OpenShift 场景中，文章提到 OVN 环境中有 ovn-bgp-agent + EVPN 的实现，但那是针对虚拟机 + provider network 的场景，不完全等同于 Kubernetes Pod 网络场景。 (Red Hat Developer)

🔍 对你关心的 “EVPN Fabric 与 OVN-Kubernetes 插件有关系吗” 的结论

可以这么说：

  • 是的，OVN-Kubernetes 插件是 OpenShift 网络层的重要组成，在 OpenShift 的网络架构中扮演主要角色。

  • 与 EVPN Fabric 的集成，是 OpenShift 网络功能中一个正在被推进的方向，特别是在 UDN + BGP 集成场景中。

  • 但现阶段 尚未 明确公开资料显示 OVN-Kubernetes 在 OpenShift 中已全面支持 “Fabric EVPN + VNI 映射 +物理交换机 VTEP 对接” 这一完整链路。

  • 如果你想实现 “OpenShift cluster + EVPN Fabric (VXLAN/VNI) +租户隔离” 的方案，那么你可能需要：

    1. 检查你所用 OpenShift 版本是否支持 EVPN 扩展功能（文档中提 “未来将扩展 EVPN”）。
    2. 确认 OVN-Kubernetes 是否支持你需要的隧道协议（如果 Fabric 用 VXLAN，有可能要配置 OVN 支持 VXLAN 或使用物理/软件网关桥接）。
    3. 与网络设备厂商（交换机／Fabric）确认其对 OVN/EVPN 集成的支持情况。

如果你愿意，我可以帮你查找 具体哪一个 OpenShift 版本（例如 4.18, 4.19）支持 “EVPN (VXLAN) with OVN-Kubernetes” 并且找出其配置文档／样例。你要吗？

好——下面给出一份深入、逐层的技术分析，解释 ovn-bgp-agent 在 OpenStack/OVN 中如何通过 EVPN 暴露 provider/tenant 网络（VNI/VRF），以及为什么该实现“更自然地针对 VM/provider-network 场景”，而不完全等同于 Kubernetes Pod 网络（尤其是 OVN-Kubernetes 的默认 Geneve Pod 网络）。我把内容分成：概念回顾 → ovn-bgp-agent 的实现细节（控制/数据平面、流程）→ 为什么面向 VM/provider network → 为什么与 Pod 网络不同 / 限制 → 可选的 Pod-侧集成路径与工程建议。关键证据在每部分末尾给出引用。

一、相关概念快速回顾（为后面分析做铺垫）

  • EVPN（MP-BGP EVPN） ：用 MP-BGP 做控制平面来分发 MAC/IP（MAC-IP NLRI）、VNI、Route-Target/RD 等信息，从而实现 VXLAN overlay 的 L2/L3 扩展与多租户隔离。
  • VNI / L2VNI / L3VNI / VRF：VNI 表示 VXLAN 的二层租户域；L3VNI（或将 VNI 映射到 VRF）用于实现租户的三层路由域。
  • OVN（OVS + OVN DB）与 OVN-Kubernetes：OVN 管理逻辑网络（logical switches/routers）并下发 OVS flow；OVN-Kubernetes 将 Pod 当作 logical port 管理，OVN 默认 East-West 隧道协议为 Geneve（OVN-Kubernetes 默认用 Geneve）。 (docs.openstack.org)

二、ovn-bgp-agent 的角色与总体架构（高层）

ovn-bgp-agent 是一个守护进程（Python），运行在节点（controller/compute/networker）上，职责是：

  1. 监听 OVN Southbound/Northbound DB 的变更（哪些网络/端口需要对外暴露）。
  2. 根据配置，使用 FRR（或路由栈）建立 BGP 会话，把需要暴露的 IP/MAC/VNI 信息通过 MP-BGP EVPN 发布到下游/上游交换机（Fabric）。
  3. 在本地节点上配置相应的 OVS/内核路由/隧道设备（比如创建 vxlan 设备、bridge、VRF、路由表、必要的 flows），以便把本地 VM/port 的流量正确重定向到 overlay/underlay。 (docs.openstack.org)

简言之：ovn-bgp-agent 把 OVN 的“逻辑端口/网段/路由”翻译并注入到物理路由域（BGP/EVPN + 设备 NVE）中，同时在本地做数据面接入和转发配置。

相关示例/设计文档还展示了 external_ids/port 注解如何携带 BGP/EVPN 元数据（如 VNI、AS、route-target），ovn-bgp-agent 检测到后会在本地建立相应 vxlan/bridge/vrf 并用 FRR 宣告这些前缀。 (Luis Tomás' Blog)

三、数据平面 & 控制平面详细流程（逐步）

下面以「将某个 provider network / tenant network 暴露到 EVPN Fabric」为例，分步说明 ovn-bgp-agent 在控制面与数据面做了什么：

  1. 配置与标记

    • 在 OVN 的 NB/SB DB 中，某个 logical_switch/port 被标记为“需要通过 EVPN 暴露”，相关 metadata（比如 VNI/EVPN type/L3VNI/route-target）会写到 external_ids 或 port 的 annotation 上。OVN 的上层插件（如 OpenStack 或特殊 UDN/服务）负责写入这些信息。 (Luis Tomás' Blog)

  2. agent 检测并准备本地数据面

    • ovn-bgp-agent 监听 DB 变更后：在本地创建/配置 OVS provider bridge 或 kernel 网络实体，创建 vxlan/nve 接口或桥接，创建 VRF（若为 L3VNI），并在本机的路由表/iptables/flow 中配置把目标流量导向 OVN 隧道或 provider bridge。
    • 这一步确保了当 Fabric 将流量发到本节点（基于 VNI），节点内能把流量导入到 OVN 的 logical datapath（送到正确 VM/port）。 (docs.openstack.org)

  3. 通过 FRR 发起 BGP/EVPN 广告

    • agent 配置 FRR（或本地 BGP）与 Fabric 的 BGP peer 建立会话，并基于 OVN 中的端口/子网信息生成 EVPN L2/L3 NLRI（例如 MAC/IP NLRI、L3VNI route、RT/RD）。这些 NLRI 会被发送到下游的 Leaf/Spine，完成 Fabric 的路由/转发表更新。 (docs.openstack.org)

  4. Fabric 收到 EVPN 通告后

    • Fabric（Nexus/Arista 等）根据 EVPN NLRI 更新其 NVE/VNI 映射、MAC 表与路由表，使得物理交换网络可以直接把对应 VNI 的流量送到正确的 VTEP（可能是 compute node）。

  5. 转发路径

    • 外部到 VM：Packet 到达 Fabric → 根据 VNI/EVPN 定位到某个 compute node 的 NVE → 该节点上已创建的 vxlan/nve 接口收到并通过 OVN/OVS flows 导入到 VM。
    • VM 到外部：VM 发包 → OVN datapath/OVS 将流量交给 provider bridge/vxlan 接口 → local FRR/agent 确保路由与 ARP/NDP 正确 → BGP/EVPN 告知 Fabric 下一跳信息。 (docs.openstack.org)

四、为什么这套设计“天然适合 VM / provider-network 场景”？

关键原因可以归为三点：

  1. provider network / VM 网络相对稳定、端口与 VNI 映射明确

    • OpenStack 的 provider network、tenant network 通常在创建时就有明确 VNI/VRF 定义（相对静态），ovn-bgp-agent 只需对这些固定映射进行配置与通告。VM 的生命周期与 IP/MAC 管理相对可控（与裸机/VM 的生命周期相比），因此 EVPN 的 MAC/IP 广告可接受且容易管理。 (Luis Tomás' Blog)

  2. OVN 在 OpenStack 场景已有“provider bridge / provider port”机制

    • OVN 的 model & OpenStack 的接口（以及 OVN BGP Agent 的设计）本来就是把 provider/tenant network 映射到物理网络的一种设计；agent 在每个节点上做本地的桥接/VRF/flows 配置非常直接。也就是说，数据面路径和 control-plane 注入点非常明确。 (docs.redhat.com)

  3. 运维和可控性（BGP/EVPN 在 Fabric 侧的成熟度）

    • 大多数 DC 交换机对 EVPN+VXLAN 的支持成熟，运维（RD/RT、RT filtering、route target）已有成熟实践，便于基于 tenant/route-target 做隔离和导入导出策略。OVN BGP Agent 正是利用这些成熟能力把 OVN 的逻辑网络暴露给 Fabric。 (docs.openstack.org)

五、为什么“不完全等同于 Kubernetes Pod 网络（问题与限制）”

尽管技术上可以把 Pod 的 IP/MAC 通告到 EVPN，但存在若干 实务与工程挑战，使得直接把 ovn-bgp-agent 的 OpenStack 模式原封不动用于 Pod 网络并不理想：

  1. Pod 的高频动态性（churn） vs EVPN 的规模/稳定性要求

    • Pod 的创建/销毁、IP 频繁变动，若每个 Pod 的 MAC/IP 都通过 EVPN 广告，会导致 MAC/IP 广告洪泛、BGP 更新量巨大、Fabric MAC 表频繁振荡，给控制面和交换设备带来可扩展性问题（尤其在大规模 K8s 集群里）。这与 VM 场景下更低的 churn 形成对比。 (Luis Tomás' Blog)

  2. 封装协议不一致（OVN-Kubernetes 默认 Geneve）

    • OVN-Kubernetes 默认使用 Geneve（而 EVPN Fabric 通常基于 VXLAN）。若 Pod datapath 是 Geneve，Fabric 不能直接作为 VTEP 解析 Geneve，必须引入协议翻译/网关（VXLAN↔Geneve），增加复杂度与延迟。OVN 在某些混合场景支持 VXLAN（或 hybrid overlay），但默认并非 VXLAN。 (Microsoft Learn)

  3. 安全/策略模型差异

    • Kubernetes 的隔离更多依赖 NetworkPolicy、CNI 内部身份/标签系统（如 OVN 的 logical switch/ACL）。将每个 Pod 广告到 Fabric 会把 Pod IP/MAC 暴露到物理网络，可能突破租户边界或引入安全风险。通常更希望在 L2/L3 之上用 L3+策略做隔离，而不是在物理 Fabric 级别直接暴露大量 Pod 条目。 (docs.okd.io)

  4. 运维/映射复杂性（namespace→VNI 的自动化）

    • 要做到“每个 Namespace/tenant 对应一个 VNI”需要在 OVN 层、agent、以及上层控制器间做好映射与同步（谁来下发 VNI、如何处理冲突、如何回收 VNI）。OpenStack 的 provider network 机制天然支持 VNI 指定，但 K8s 的 namespace 概念需要额外控制平面（或 operator）去管理映射。OVN 社区有 OKEP/提案（如 OKEP-5296）在推进这方面能力，但仍非开箱即用。 (ovn-kubernetes.io)

  5. 性能与表项限制

    • 物理交换设备的 MAC 表、EVPN 路由表的规模有限。把海量 Pod 映射到 Fabric 可能触及硬件表项或路由收敛性能瓶颈。VM 场景通常租户规模与 VM 数量对比 Pod 更可控。 (docs.openstack.org)

六、典型的 Pod-侧集成策略（工程实践选项）

如果确有必要把 Kubernetes/Pod 网络与 EVPN Fabric 结合，常见的工程做法是折衷、分层地实现，而不是 1:1 把每个 Pod 的 MAC/IP 广告到 Fabric：

  1. 把 Namespace/租户映射成 Logical Switch + 单个 VNI（L2）或 L3VNI

    • 将 Namespace 映射到 OVN 的一个 logical_switch，并为该 logical_switch 指定一个 VNI（或 L3VNI），只把 logical_switch 的网段（而不是每个 Pod）通过 ovn-bgp-agent 通告到 Fabric（即广告子网/网段和网关 IP），Fabric 在 VNI 层做隔离。这样把表项规模从 “Pod 级别” 降到 “网段/租户 级别”。（需要上层控制器写入 external_ids/vni 信息给 OVN）。相关社区提案和示例有在讨论中。 (docs.openstack.org)

  2. 使用 Provider Network / Hybrid Overlay

    • 在节点上配置 provider bridge（或 NATIVE 接口）把部分服务/VM/特殊 Pod 暴露到 Fabric；普通 Pod 仍留在 Geneve 隧道内。OpenShift/OVN 有 hybrid overlay 或专门的 hybrid-ovn 方案能做 VXLAN 到外部设备的桥接。F5 的文档有 hybrid overlay 示例：内部用 Geneve，外部与设备对接用 VXLAN。 (F5 Cloud Docs)

  3. BGP Control-Plane（路由等级）而非 EVPN 广告 Pod MAC

    • 让 Kubernetes/CNI 仅通过 BGP 广告 Pod 子网或服务 IP（而不是 MAC），把 L3 reachability 注入 Fabric；对于 L2 扩展或 VM-to-Pod 的 L2 需求，通过边缘网关/翻译器来完成。OVN-BGP agent 支持 L3VNI/route 发布示例。 (docs.openstack.org)

  4. 集中翻译网关（VXLAN↔Geneve）

    • 在边缘或特定网关节点做协议翻译，把 Geneve 封装流量转换成 Fabric 可识别的 VXLAN/VTEP 流量；适合在无法改动 Fabric 的情况下逐步集成，代价是额外桥接/网关复杂度与性能开销。

七、结论（要点汇总）

  • ovn-bgp-agent 通过监听 OVN DB、在本地配置 vxlan/bridge/VRF、并通过 FRR 注入 MP-BGP EVPN NLRI，把 OVN 的 provider/tenant 网络暴露到物理 EVPN Fabric，这是 OpenStack 场景下成熟的做法。 (docs.openstack.org)
  • 该做法天然适合 provider network / VM 场景（稳定、VNI 映射明确、可控性高），但直接把 Pod 的 MAC/IP 广告到 Fabric 会面临 churn、规模与封装协议不匹配（OVN-Kubernetes 默认 Geneve）等挑战。 (Microsoft Learn)
  • 工程上常用折衷：把“租户映射到 VNI/网段”而非 Pod 级别广告，或采用 hybrid overlay /翻译网关、或仅做 L3 BGP 广告以降低表项压力；OVN-Kubernetes 社区也在推进对 BGP/EVPN 的更好集成（OKEP 等提案）。 (ovn-kubernetes.io)
avatar
文章
阅读
粉丝