Skip to main content

CNI 是什么​

CNI 规范概述​

CNI（Container Network Interface，容器网络接口）是由CNCF（Cloud Native Computing Foundation，云原生计算基金会）托管的容器网络项目。项目维护接口规范和开发库，同时提供一组参考插件。

CNI规定了容器运行时调用网络插件的方式。containerd、CRI-O等兼容CRI（Container Runtime Interface，容器运行时接口）的运行时，会按照这套约定调用插件，为容器创建或清理网络连接。

CNI只定义如何建立和删除容器网络连接，不限定数据平面的具体实现。Kubernetes（常简称为K8s）、Nomad、Apache Mesos等系统都支持该规范。

CNI 工作原理​

网络插件通常是一个可执行文件。容器运行时调用插件时，通过标准输入（stdin）传入JSON（JavaScript Object Notation，JavaScript 对象表示法）配置，再通过环境变量传入容器 ID、网络命名空间等参数。插件主要处理以下三种操作：

  • ADD：将容器加入网络，包括分配IP地址、配置路由和设置网络接口。IP是Internet Protocol（网际协议）的缩写
  • DEL：将容器移出网络，释放IP地址并清理网络配置
  • CHECK：检查容器网络配置是否正确。该操作可选，由CNI规范0.4.0引入

下图展示了CNI在Kubernetes中的工作流程：

Kubernetes 中的 CNI 组件​

Kubernetes本身不提供完整的网络数据平面，而是按照CNI规范调用第三方网络插件。Kubernetes网络模型有以下基本要求：

  • 任意两个Pod都可以直接通信，无需经过NAT（Network Address Translation，网络地址转换）
  • 任意节点都可以直接访问任意Pod，无需经过NAT
  • Pod在容器内看到的IP地址，与其他Pod用来访问它的IP地址相同

Kubernetes不强制使用某一种CNI实现。在当前版本中，节点上的CRI容器运行时负责加载和调用已安装的CNI插件，配置文件通常位于/etc/cni/net.d/。kubelet --network-plugin和--cni-bin-dir参数已在Kubernetes 1.24中移除，不再适用于现代集群。

主流 CNI 插件概览​

常见的CNI插件和组件大致可分为以下几类：

类型代表插件主要特征
Overlay（覆盖网络）Flannel、Calico或Cilium的隧道模式通过隧道封装实现跨节点通信，部署灵活，但会增加封装和处理开销
Underlay（承载网络）/路由模式Calico BGP（Border Gateway Protocol，边界网关协议）模式、Cilium Native Routing直接使用节点路由，性能通常更好，但需要底层网络配合
基于eBPF（extended Berkeley Packet Filter，扩展伯克利包过滤器）的数据平面Cilium在Linux内核中运行eBPF程序，提供高性能数据路径和网络策略
多网卡元插件Multus允许Pod挂载多个网络接口，常与SR-IOV（Single Root I/O Virtualization，单根I/O虚拟化）结合使用
高性能设备接入SR-IOV CNI、RDMA CNI和设备插件RDMA是Remote Direct Memory Access（远程直接内存访问）的缩写。这些组件分别负责配置VF（Virtual Function，虚拟功能）、分配设备和隔离RDMA网络命名空间
云厂商定制方案阿里云Terway、AWS（Amazon Web Services，亚马逊云科技）VPC CNI与云平台的VPC（Virtual Private Cloud，虚拟私有云）和网卡能力深度集成

Flannel​

Flannel是较早的Kubernetes网络插件之一。它为每个节点分配一段Pod子网，再通过不同后端实现跨节点通信。

Flannel支持多种后端：

  • VXLAN（Virtual Extensible LAN，虚拟扩展局域网）：最常用的后端之一。它在内核中封装数据包，方便跨三层网络部署，代价是额外的封装和处理开销
  • host-gw：直接通过节点路由转发，不使用隧道封装。这种模式通常要求节点之间二层可达
  • UDP（User Datagram Protocol，用户数据报协议）：一种早期后端，数据路径需要经过用户态，性能较低，不适合高吞吐的生产环境

Calico​

Calico是常见的生产级网络和网络策略方案，由开源社区和Tigera维护。它主要支持以下网络模式：

  • BGP非封装模式：使用BGP分发Pod路由，不为数据包增加隧道头。能否使用该模式，取决于底层网络是否能够承载这些路由
  • IPIP（IP-in-IP，IP套IP）模式：在BGP基础上增加同名封装，适用于跨子网场景
  • VXLAN模式：类似Flannel的VXLAN模式，适用于不支持BGP的环境

Calico还提供完整的网络策略（NetworkPolicy）能力，可以通过eBPF或iptables对流量进行精细控制。

Cilium​

Cilium是一个基于Linux内核eBPF技术的网络、可观测性和安全项目。项目最初由Isovalent发起，2021年进入CNCF孵化阶段，2023年毕业。它的主要特点包括：

  • 使用内核中的eBPF程序实现主要数据路径、网络策略和服务负载均衡，降低对大量iptables规则的依赖
  • 在负载均衡等特定路径上使用XDP（eXpress Data Path，快速数据路径）尽早处理数据包。是否可以启用、实际收益如何，取决于网卡、内核和部署模式
  • 可以替代kube-proxy，使用eBPF实现Service负载均衡
  • 集成Hubble可观测平台，用于展示和分析网络流量

基础 Pod 网络在大模型训练中的挑战​

大模型训练的网络需求​

大规模分布式训练需要持续进行跨节点集合通信，网络流量特征与常见的请求-响应型微服务很不一样。实际网络需求取决于模型规模、并行策略、每个节点的加速卡数量，以及计算与通信能否有效重叠，不能只看模型参数量。

训练任务常用NCCL（NVIDIA Collective Communications Library，NVIDIA 集合通信库）或MPI（Message Passing Interface，消息传递接口）完成跨进程和跨节点通信。下表对比了微服务与大模型训练的典型网络特征：

维度传统微服务场景大模型训练场景
通信模式多为请求-响应或消息流AllReduce、AllGather、ReduceScatter等集合通信
带宽需求因服务而异，通常不会持续占满链路常持续占用高带宽；单节点可能汇聚多条100/200/400 Gbps链路
延迟敏感性通常关注尾延迟同步集合通信对延迟和抖动敏感，慢节点可能拖慢整个作业
网络利用率常呈突发或不均匀分布通信阶段可能长时间接近链路上限
关键软件/传输HTTP、gRPC、TCP等NCCL、MPI；可使用IP Socket（IP套接字）、RDMA或厂商网络插件
故障影响可通过副本和重试局部恢复通信成员故障通常会导致当前分布式作业失败、超时或等待恢复

分布式训练会通过AllReduce、AllGather、ReduceScatter等集合通信原语，同步梯度、参数或激活值。以NCCL为例，当训练扩展到多个节点后，网络可能成为主要瓶颈之一。但最终是否受限于网络，仍需结合并行策略和性能剖析结果判断。

Overlay 封装带来的性能损耗​

部分CNI方案会使用Overlay封装，例如Flannel VXLAN或Calico IPIP/VXLAN模式。发送端需要为数据包增加外层头部，接收端再将其拆除，主要会带来以下开销：

  • 额外延迟：隧道处理和更长的数据路径会增加时延和抖动。实际影响取决于内核实现、网卡卸载能力、MTU（Maximum Transmission Unit，最大传输单元）、报文大小和节点拓扑，不能简单用一个固定的微秒数概括。

  • 封装开销与MTU：典型IPv4 VXLAN封装的外层以太网、IP、UDP和VXLAN头合计约50字节。如果底层MTU没有相应增大，数据包可能被分片，或者必须调低Pod侧的MTU。对小报文而言，新增头部所占的比例更高。

  • CPU资源消耗：封装和解封装会占用CPU（Central Processing Unit，中央处理器）。在高吞吐场景下，这部分开销可能间接降低GPU（Graphics Processing Unit，图形处理器）的有效利用率。

基础 CNI 不会单独提供 RDMA 设备能力​

NCCL和MPI都可以通过IP Socket通信，并不强制使用RDMA。但在大规模训练中，InfiniBand（面向高性能计算的互连技术）、RoCE（RDMA over Converged Ethernet，融合以太网上的RDMA）或其他内核旁路传输，通常可以提供更低的时延、更高的吞吐量，并减少CPU数据路径开销。

在InfiniBand/RDMA网络中，连接主机与互连网络的适配器通常称为HCA（Host Channel Adapter，主机通道适配器）。RDMA可以让HCA直接读写已注册的应用内存，减少传统Socket数据路径中的多次拷贝和内核协议栈处理。

不过，建立传输、注册内存和处理完成通知仍可能消耗CPU，因此不能把RDMA简单理解为“完全不占用CPU”。链路带宽也会随代际变化，例如InfiniBand HDR（High Data Rate，高数据速率）为200 Gbps，NDR（Next Data Rate，下一代数据速率）为400 Gbps。

如果希望网卡直接访问GPU显存，则需要GPUDirect RDMA。除了RDMA网络，还需要兼容的GPU、NIC（Network Interface Card，网卡）和驱动，以及合适的PCIe（Peripheral Component Interconnect Express，高速串行计算机扩展总线标准）拓扑。因此，普通RDMA可用并不代表GPUDirect RDMA一定可用。

Flannel、Calico和Cilium等基础CNI主要负责Pod的普通IP网络。它们通常不会安装RDMA驱动、把HCA注册为可调度资源、向容器注入/dev/infiniband/*设备，也不会隔离RDMA网络命名空间。因此，只安装基础CNI的集群，通常还不能直接调度RDMA工作负载。

基础CNI并不会阻止RDMA，它也无需理解所谓的“RDMA语义”。常见做法是保留基础CNI承担管理网络，再根据隔离需求补充RDMA设备插件和附加网络。可选方式包括MacVLAN（一种基于MAC地址创建虚拟接口的Linux网络驱动；MAC是Media Access Control，即媒体访问控制）、IPoIB（IP over InfiniBand，在InfiniBand上承载IP）、Host Device（将物理设备直接交给Pod），以及Multus + SR-IOV CNI + RDMA CNI。

单网卡架构的局限性​

典型Kubernetes集群只为每个Pod配置一个主网络接口，通常是eth0。Kubernetes上游核心API（Application Programming Interface，应用程序编程接口）尚未定义通用的多网络接口模型，而训练集群往往有以下需求：

  • 分离训练网络与管理网络：可以将NCCL集合通信与Kubernetes控制、监控和日志流量放在不同的接口、VLAN（Virtual Local Area Network，虚拟局域网）或物理网络上，减少彼此争用带宽。是否需要做物理隔离，取决于集群规模、安全要求和故障域设计。

  • 并行使用多张高速网卡：高端训练节点通常配有多个高速端口或HCA。单个Pod需要访问与GPU拓扑匹配的多个设备，并借助NCCL多轨（Multi-Rail）等能力利用聚合带宽。

  • 隔离存储网络：可以让训练数据加载、检查点（Checkpoint）保存等存储I/O（Input/Output，输入/输出）操作走独立的高速网络，避免挤占训练网络的带宽。

这些能力通常由Multus等多网络元插件，或云厂商的设备接入机制提供，不是Kubernetes默认网络API的职责。

QoS 和流量优先级能力有限​

在大规模训练集群中，集合通信、数据读取和检查点写入对QoS（Quality of Service，服务质量）的要求并不相同。基础CNI可以提供部分主机侧限速、带宽管理和网络策略能力，但无法独立完成RoCE无损网络所需的端到端配置。PFC（Priority Flow Control，优先级流量控制）、ECN（Explicit Congestion Notification，显式拥塞通知）、拥塞控制和交换机队列都需要统一设计。选型时，应分别评估主机数据面、网卡和物理交换网络。

规模扩展性问题​

集群规模扩大后，需要重点关注路由或隧道状态的数量、策略更新速度、IP地址容量、故障收敛和可观测性。Overlay并不会在达到某个固定节点数后必然失效，BGP或原生路由也不一定更容易扩展。实际结果取决于插件实现、控制面拓扑和底层网络。建议按目标节点数、Pod数和策略数进行压测，而不是根据固定规模阈值直接选型。

业界高性能训练网络与 Kubernetes 集成实践​

常见独占式架构：Multus + SR-IOV + RDMA​

如果需要把RDMA VF独占分配给训练Pod，可以采用下图所示的分层架构。但SR-IOV并非唯一选择，共享HCA、Host Device和云厂商设备插件也都可行。NVIDIA Network Operator官方快速入门分别给出了SR-IOV RDMA、Host Device RDMA和MacVLAN + RDMA Shared Device三种部署示例。

这套架构包含以下核心组件：

  • Multus CNI：由k8snetworkplumbingwg维护的元插件（Meta Plugin）。Multus负责调用默认CNI和附加CNI，让单个Pod获得多个网络接口。管理员先通过NetworkAttachmentDefinition定义附加网络，再在Pod的k8s.v1.cni.cncf.io/networks注解中引用。资源和注解的具体格式见Multus项目文档。

  • SR-IOV设备插件与CNI：SR-IOV可以把一个物理功能（Physical Function，PF）划分为多个虚拟功能（Virtual Function，VF）。SR-IOV Network Device Plugin负责发现VF，并将其注册为Kubernetes扩展资源。SR-IOV CNI则在创建Pod时配置被分配的VF，并将其移入Pod网络命名空间。SR-IOV Network Operator可以进一步自动配置节点上的PF、VF和相关资源。

  • RDMA设备插件与RDMA CNI：两者承担的职责不同。RDMA Shared Device Plugin或启用RDMA选择器的SR-IOV设备插件负责发现资源和分配设备。RDMA CNI是一个链式CNI，负责把网络接口关联的RDMA设备移入Pod网络命名空间，实现RDMA接口隔离；它本身不会注册扩展资源。

典型配置示例​

下面的配置参考了RDMA CNI上游的NetworkAttachmentDefinition示例，展示如何通过Multus为训练Pod附加SR-IOV RDMA网络。其中，IPAM（IP Address Management，IP 地址管理）插件负责为附加网络分配地址：

# 定义SR-IOV网络附件
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: sriov-rdma-net
  namespace: default
  annotations:
    k8s.v1.cni.cncf.io/resourceName: mellanox.com/sriov_rdma
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "name": "sriov-rdma-net",
      "plugins": [
        {
          "type": "sriov",
          "ipam": {
            "type": "host-local",
            "subnet": "192.168.100.0/24"
          }
        },
        {
          "type": "rdma"
        }
      ]
    }
# 训练 Pod 配置
apiVersion: v1
kind: Pod
metadata:
  name: training-pod
  annotations:
    # 申请 2 个 SR-IOV RDMA 网络接口
    k8s.v1.cni.cncf.io/networks: |
      [
        {"name": "sriov-rdma-net", "interface": "net1"},
        {"name": "sriov-rdma-net", "interface": "net2"}
      ]
spec:
  containers:
  - name: trainer
    resources:
      limits:
        # 申请 GPU 资源
        nvidia.com/gpu: "8"
        # 申请 RDMA 虚拟功能资源
        mellanox.com/sriov_rdma: "2"

该示例还有两个前提条件：首先，SR-IOV设备插件需要提前创建名为mellanox.com/sriov_rdma且已启用RDMA的资源池；其次，节点必须满足RDMA CNI列出的硬件、内核和部署要求。

host-local IPAM只在本机保存地址分配状态，具体行为见CNI host-local插件文档。在生产环境中，不应让所有节点复用同一地址池。可以为每个节点划分独立网段，也可以改用具备集群级协调能力的IPAM。

Meta：两套方案并行验证​

Meta在2024年3月发布的官方工程文章《Building Meta's GenAI Infrastructure》中，公布了两套大规模集群网络方案，每套集群都包含24,576张NVIDIA H100 GPU。下文的网络设备、端点速率、Llama 3训练状态和性能数据均来自该文章。

  • 方案一：RoCE：基于Arista 7800以及Wedge400、Minipack2等OCP（Open Compute Project，开放计算项目）机架交换机构建，端点速率为400 Gbps。文章发布时，Meta正在这套RoCE集群上训练Llama 3。

  • 方案二：InfiniBand：基于NVIDIA Quantum-2 InfiniBand构建，端点速率同样为400 Gbps。Meta并没有在文中得出“InfiniBand必然优于RoCE”的结论，因此也不能只根据协议名称判断两套方案的实际性能。

Meta用这两套方案评估不同互联技术在大规模集群中的适用性和可扩展性。官方文章的性能章节显示，经过拓扑感知调度、路由和NCCL优化后，大集群在文中测试条件下的归一化集合通信利用率恢复到90%以上。这一结果仅适用于文中的消息大小和网络环境，不能当作通用保证。

这篇公开文章介绍了Meta的内部作业调度器，但没有说明是否使用Kubernetes、Multus或某种CNI。因此，这一案例只用来说明Meta公开的RoCE和InfiniBand网络设计，不能作为其Kubernetes CNI选型的证据。

AWS：EFA（Elastic Fabric Adapter，弹性结构适配器）+ VPC CNI 多网卡方案​

AWS为多种HPC（High Performance Computing，高性能计算）和加速实例提供EFA。根据AWS EFA官方说明，标准EFA同时提供ENA（Elastic Network Adapter，弹性网络适配器）网络能力，以及基于SRD（Scalable Reliable Datagram，可扩展可靠数据报）的OS-bypass（Operating System bypass，操作系统旁路）接口。应用通过libfabric和对应的MPI/NCCL适配层使用EFA。

在Kubernetes上使用EFA时，AWS的组件分工如下：

  • Pod IP网络：根据Amazon VPC CNI工作方式，VPC CNI通常从节点ENI（Elastic Network Interface，弹性网络接口）的辅助IP或前缀中，为Pod分配VPC地址，而不是让每个Pod独占一张完整的ENI
  • EFA设备：EKS EFA部署文档说明，EFA接口会随EC2（Elastic Compute Cloud，弹性计算云）节点一起配置，AWS EFA Kubernetes Device Plugin再将其注册为vpc.amazonaws.com/efa扩展资源
  • Pod申请：EKS文档中的工作负载示例通过requests/limits申请一个或多个EFA。官方流程并没有把Multus列为前置组件

EFA对资源暴露方式、节点拓扑、Huge Pages、实例类型和VPC CNI版本都有明确要求。部署前应根据当前EKS和EC2文档检查兼容性。

NVIDIA Network Operator​

根据NVIDIA Network Operator官方文档，该Operator用于在Kubernetes中部署和管理NVIDIA网络驱动、设备插件和附加网络组件。项目的开源仓库为Mellanox/network-operator。根据配置，它可以管理以下全部或部分组件：

组件功能
DOCA-OFED Driver Container（DOCA即Data Center Infrastructure-on-a-Chip Architecture，OFED即OpenFabrics Enterprise Distribution）或主机驱动为节点提供NVIDIA网卡驱动和RDMA软件栈
SR-IOV Network Operator自动配置SR-IOV虚拟功能
RDMA Shared Device Plugin将RDMA设备注册为Kubernetes扩展资源
Multus CNI部署多网卡元插件
CNI Plugins与IPAM按需部署MacVLAN、IPoIB、Whereabouts/NVIDIA IPAM等组件
Node Feature Discovery发现节点硬件特性，供组件选择节点

NVIDIA Network Operator通过NicClusterPolicy等CRD（Custom Resource Definition，自定义资源定义）统一描述驱动和网络组件。部署指南也列出了需要另外创建的网络和IPAM资源。Operator可以降低组件生命周期的管理成本，但不能替代底层交换网络和拥塞控制设计。

# NicClusterPolicy示例
apiVersion: mellanox.com/v1alpha1
kind: NicClusterPolicy
metadata:
  name: nic-cluster-policy
spec:
  ofedDriver:
    image: doca-driver
    repository: nvcr.io/nvidia/mellanox
    version: "<与Operator兼容的版本>"
  rdmaSharedDevicePlugin:
    image: k8s-rdma-shared-dev-plugin
    repository: nvcr.io/nvidia/mellanox
    version: "<与Operator兼容的版本>"
    config: |
      {
        "configList": [{
          "resourceName": "rdma_shared_device_a",
          "rdmaHcaMax": 63,
          "selectors": {"ifNames": ["ens1f0"]}
        }]
      }
  secondaryNetwork:
    cniPlugins:
      image: plugins
      repository: nvcr.io/nvidia/mellanox
      version: "<与Operator兼容的版本>"
    multus:
      image: multus-cni
      repository: nvcr.io/nvidia/mellanox
      version: "<与Operator兼容的版本>"

上述字段结构参考了NVIDIA Network Operator的RDMA Shared Device Plugin部署示例。实际部署时，镜像名、仓库、版本和选择器都必须以已安装Operator的兼容矩阵和节点网卡名称为准，不能直接使用示例中的占位值。

Cilium：eBPF 高性能方案​

Cilium可以作为训练集群的管理网络CNI。与本文选型相关的能力主要有以下几项：

高性能数据路径：

  • Cilium的eBPF Host-Routing可以减少主机网络路径对netfilter/iptables规则遍历的依赖。性能调优文档指出，BIG TCP可以将IPv4/IPv6的GSO（Generic Segmentation Offload，通用分段卸载）/GRO（Generic Receive Offload，通用接收卸载）聚合上限从典型的64 KiB提高到约192 KiB，但前提是内核、网卡和部署模式均兼容
  • Cilium支持kube-proxy替换，使用eBPF实现Service负载均衡。是否会发生SNAT（Source NAT，源地址转换）、数据包会走哪条转发路径，仍取决于具体配置，因此不能简单理解为完全消除了DNAT（Destination NAT，目的地址转换）和SNAT

可观测性：

  • Hubble官方说明表明，它的可见性建立在Cilium和eBPF数据路径之上。EFA的OS-bypass说明和GPUDirect RDMA文档描述的则是绕过普通内核网络栈的数据路径。因此，Hubble不能作为RDMA verbs（RDMA操作接口）的完整观测工具，也不应被当作直接定位集合通信慢节点的工具

多租户隔离：

  • Cilium的网络策略语言支持L3/L4（网络层/传输层）和部分L7（应用层）协议控制，可以限制不同训练任务之间的网络访问。但网络策略解决的是访问控制问题，不能替代带宽QoS，也无法消除共享链路上的性能干扰

Cilium文档并没有把RDMA HCA发现和分配列为CNI能力。这部分职责由RDMA Shared Device Plugin或SR-IOV设备插件承担。因此，Cilium可以继续承担管理网络，RDMA附加网络再根据前述NVIDIA官方部署模式选择共享HCA、Host Device或SR-IOV VF。

阿里云 Terway CNI​

根据Terway项目说明，Terway是面向阿里云ACK（Alibaba Cloud Container Service for Kubernetes，阿里云容器服务 Kubernetes 版）的开源CNI，基于阿里云VPC和ENI能力构建。它的核心特性包括：

  • ENI网络模式：Terway项目文档说明，Terway为Pod分配VPC地址，并通过节点ENI直接进入VPC，跨节点流量无需使用VXLAN等Overlay封装。每个Pod是独占ENI，还是使用共享ENI上的IP，取决于具体模式
  • eBPF加速与网络策略：Terway项目文档列出了eBPF数据路径加速和Kubernetes NetworkPolicy支持
  • eRDMA（Elastic Remote Direct Memory Access，弹性远程直接内存访问）协同：Alibaba Cloud eRDMA Controller负责在Kubernetes中管理eRDMA设备。Terway仓库的eRDMA共存设计说明进一步列出了两者的职责划分以及版本、IPAM模式限制。因此，安装Terway并不代表集群会自动获得RDMA能力

云上方案通常与实例规格、地域、集群版本和托管组件紧密关联。部署前应以当前ACK和eRDMA产品文档为准。

技术方案对比与选型建议​

方案与组件组合对比​

方案或组件组合主要职责RDMAGPUDirect RDMA
Flannel/Calico/Cilium基础网络Pod主IP、路由、Service和网络策略本身不负责将HCA注册为可调度资源，但可与RDMA组件共存本身不支持；需要额外RDMA设备和GPU/NIC直接数据路径
RDMA Shared Device Plugin + MacVLAN/IPoIB多个Pod共享物理HCA支持可支持；需验证GPU/NIC拓扑、驱动、通信库和容器权限
Multus + SR-IOV 设备插件/CNI + RDMA CNI为Pod附加并隔离RDMA VF支持可支持；需验证VF、GPU/NIC拓扑、驱动和通信库兼容
NVIDIA Network Operator自动部署驱动、设备插件和附加网络组件取决于启用的组件取决于启用的驱动、设备插件、网络模式和硬件拓扑
AWS EFA、阿里云eRDMA等云厂商高性能设备和托管集成取决于实例和服务取决于实例规格、驱动和云厂商服务支持

网络架构分层建议​

构建大模型训练集群时，建议把网络按职责分层设计：

选型原则：

  • 先量化通信需求：小规模训练，或通信占比较低的任务，可以直接使用TCP/IP。只有在基准测试证明网络是瓶颈后，才需要根据收益和成本选择RDMA或厂商内核旁路方案
  • 分开设计管理网和训练网：管理网更关注稳定性、网络策略和可观测性；训练网则更关注拓扑、吞吐量、时延、拥塞控制和故障域
  • 根据隔离需求选择RDMA接入方式：共享HCA可以提高设备利用率，SR-IOV VF则能提供更强隔离。SR-IOV是RDMA的一种接入方式，不是必要条件
  • 单独验证GPUDirect RDMA：RDMA可用不代表GPU显存直接数据路径可用。还需要检查GPU/NIC拓扑、驱动、通信库和容器权限
  • 确实需要多个网络接口时再引入Multus：Multus是常见的多网络方案，但EFA设备插件、hostNetwork或其他云厂商机制不一定依赖它
  • 端到端设计QoS：在RoCE场景中，尤其需要同时验证主机、网卡、交换机和拥塞控制配置

总结​

大规模训练的集合通信模式与常见微服务明显不同。Flannel、Calico和Cilium可以继续承担管理网络，但无法单独完成RDMA设备发现、调度、容器注入和隔离。

对于本地部署，一种常见的组合是：

  1. 管理网络：使用Flannel、Calico或Cilium等基础CNI，负责Pod基础网络互通，并根据具体实现提供网络策略和Service数据路径
  2. 训练高速网络：根据隔离要求选择共享HCA，或使用Multus + SR-IOV 设备插件/CNI + RDMA CNI
  3. 自动化运维：使用NVIDIA Network Operator等工具，管理兼容的网卡驱动、设备插件和附加网络组件

Meta的RoCE/InfiniBand集群、AWS EFA和阿里云eRDMA表明，高性能训练网络没有唯一的技术路线。这些方案的共同目标是缩短通信数据路径、减少处理开销，并做好拓扑和拥塞控制。SR-IOV + RDMA + Multus只是其中一种组合，并不适用于所有场景。

Kubernetes可以通过设备插件、附加CNI和Operator编排高性能网络，但最终性能仍取决于硬件拓扑、驱动、通信库、网络配置和调度策略。CNI只是其中一层。选型时，不能把某个网络插件的名称直接等同于端到端训练性能。

参考资料​