GPU 算力已经拉满，网络却成了性能瓶颈？在大模型训练和推理场景中，传统 TCP/IP 网络的延迟和 CPU 开销正在严重制约着整个集群的性能表现。RDMA 技术通过绕过内核直接访问内存，能够有效降低网络延迟。本文将一步步指导你在 Kubernetes 集群中启用 RDMA 能力，从 Device Plugin 部署到最终的性能验证，帮助你真正释放 AI 集群硬件的全部潜力。
1. 基本概念
RDMA (Remote Direct Memory Access) 是一种高性能网络通信技术，它允许网络中的一台计算机直接读取或写入另一台计算机的内存，而无需经过双方操作系统的内核或 CPU 参与。
1.1 核心特性
- Zero Copy (零拷贝)：应用程序可以直接将数据传输到网络适配器，无需在内核空间和用户空间之间复制数据。
- Kernel Bypass (内核旁路)：应用程序可以直接向硬件发送命令，绕过操作系统内核，从而显著降低延迟。
- CPU Offload (CPU 卸载)：网络传输逻辑由网卡硬件处理，释放 CPU 资源用于计算任务。
1.2 网络协议
RDMA 支持多种网络传输协议，常见的包括：
- InfiniBand (IB)：
- 专为高性能计算设计的网络标准。
- 提供极高的吞吐量和极低的延迟。
- 需要专用的 IB 交换机和网卡，成本较高，但性能最好。
- 采用基于信用的流控机制，保证无损传输。
- RoCE (RDMA over Converged Ethernet)：
- 允许在以太网上运行 RDMA 协议。
- RoCE v1：基于以太网链路层协议，只能在同一个二层广播域内通信，不可路由。
- RoCE v2：基于 UDP/IP 协议，可以跨三层网络路由，是目前数据中心的主流选择。需要交换机支持 PFC (Priority Flow Control) 和 ECN (Explicit Congestion Notification) 以保证无损传输。
- iWARP (Internet Wide Area RDMA Protocol)：
- 基于 TCP/IP 协议栈实现 RDMA。
- 利用 TCP 的可靠传输机制，对网络设备要求较低（普通以太网交换机即可）。
- 由于 TCP 协议栈的复杂性，性能通常低于 IB 和 RoCE。
在 Kubernetes 环境中，我们通常关注如何将这些高性能网络能力暴露给 Pod 使用。
2. 背景与目标
随着大模型（LLM）训练和推理需求的爆发式增长，分布式计算集群对网络带宽和延迟提出了前所未有的高要求。在传统的 TCP/IP 网络架构中，数据传输需要经过操作系统内核的多次上下文切换和内存拷贝，这在高带宽（如 100Gbps+）场景下会消耗大量的 CPU 资源，并引入不可忽视的延迟，最终成为制约 GPU 集群整体性能的关键瓶颈。
为了解决这一问题，RDMA 技术被广泛应用。它允许应用程序直接访问远程节点的内存，绕过了内核网络栈，从而实现了高吞吐、低延迟和极低的 CPU 占用。
然而，Kubernetes 原生并不直接支持 RDMA 设备的管理和调度。为了在 Kubernetes 集群中充分利用 RDMA 硬件能力，我们需要解决以下几个关键问题：
- 设备发现与管理：如何将物理节点的 RDMA 设备（如 IB 卡、RoCE 网卡）暴露给 Kubernetes 调度器。
- Pod 配置：如何将 RDMA 设备挂载到 Pod 内部，使其能够使用 IB Verbs API 进行通信。
- 网络方案选择：在复杂的网络环境中，是否需要引入 Multus CNI 等多网卡方案。
- 性能验证：如何验证 RDMA 功能是否正常开启，并测试实际带宽和延迟是否达标。
本文将基于 Mellanox 提供的 k8s-rdma-shared-dev-plugin，详细介绍在 Kubernetes 中启用原生 RDMA 的完整流程与最佳实践。
3. 部署 device-plugin
推荐使用由 Mellanox 官方维护的 DevicePlugin：k8s-rdma-shared-device-plugin[1]。
3.1 驱动安装
确保节点已安装对应版本的 MOFED/OFED 驱动及用户态库（libibverbs、rdmacm 等）。驱动安装方式本文不赘述。
3.2 获取部署模板
先 clone 项目：
git clone https://github.com/Mellanox/k8s-rdma-shared-dev-plugin.git
3.3 部署 Device Plugin
cd deployment/k8s/base
kubectl apply -k .
部署成功后 kube-system 中会出现 rdma-shared-dp-ds DaemonSet，它会在每个节点挂载 RDMA 设备并注册可调度资源。
root@GB200-POD2-F06-Node05:~# kubectl -n kube-system get po|grep rdma
rdma-shared-dp-ds-vrswv 1/1 Running 1 (27h ago) 31h
rdma-shared-dp-ds-zg242 1/1 Running 1 (27h ago) 31h
3.4 配置
Device Plugin 的核心是 ConfigMap。默认配置可参考：configmap.yaml[2]。
apiVersion: v1
kind: ConfigMap
metadata:
name: rdma-devices
namespace: kube-system
data:
config.json: |
{
"periodicUpdateInterval": 300,
"configList": [
{
"resourceName": "hca_shared_devices_a",
"rdmaHcaMax": 1000,
"selectors": {
"vendors": ["15b3"],
"deviceIDs": ["1021"],
"ifNames": ["ibp3s0"]
}
}
]
}
关键字段：
resourceName：Pod 申请资源写的名字，建议自定义如 rdma/ibrdmaHcaMax：单卡允许共享的 Pod 数量，默认 1000selectors：定义哪些物理网卡由 device plugin 接管，是配置的关键
- vendors：设备厂商 ID，例如 Mellanox 为 15b3
- deviceIDs：设备 ID，和 IB 卡有关，例如 ConnectX-7 为 1021
- ifNames：设备接口名称。
接下来介绍如何收集这些必需的设备信息。
4. 采集 RDMA 设备信息
4.1 列出 IB 设备
ls /sys/class/infiniband
mlx5_0 mlx5_1 mlx5_2 mlx5_3 mlx5_4 mlx5_5 mlx5_6 mlx5_7
4.2 关联网络接口
ibdev2netdev
mlx5_0 port 1 ==> ibp3s0 (Up)
mlx5_1 port 1 ==> ibP2p3s0 (Up)
mlx5_2 port 1 ==> enP6p3s0f0np0 (Up)
mlx5_3 port 1 ==> bond0 (Up)
mlx5_4 port 1 ==> ibP16p3s0 (Up)
mlx5_5 port 1 ==> ibP18p3s0 (Up)
mlx5_6 port 1 ==> enP22p3s0f0np0 (Up)
mlx5_7 port 1 ==> bond0 (Up)
这里可以看到 IB 卡对应的接口名称，例如 mlx5_0 的接口名称为 ibp3s0。
这里可以获取到配置中需要的 ifNames 参数。
4.3 获取 PCI 信息
mst status -v 可以列出所有 UP 状态网卡及其 PCI ID：
root@GB200-POD2-F06-Node05:~/lixd/rdma# mst status -v
MST modules:
------------
MST PCI module loaded
MST PCI configuration module loaded
PCI devices:
------------
DEVICE_TYPE MST PCI RDMA NET NUMA
ConnectX7(rev:0) /dev/mst/mt4129_pciconf0 0000:03:00.0 mlx5_0 net-ibp3s0 0
ConnectX7(rev:0) /dev/mst/mt4129_pciconf1 0002:03:00.0 mlx5_1 net-ibP2p3s0 0
ConnectX7(rev:0) /dev/mst/mt4129_pciconf2 0010:03:00.0 mlx5_4 net-ibP16p3s0 1
ConnectX7(rev:0) /dev/mst/mt4129_pciconf3 0012:03:00.0 mlx5_5 net-ibP18p3s0 1
BlueField3(rev:1) /dev/mst/mt41692_pciconf0 0006:03:00.0 mlx5_2 net-enP6p3s0f0np0 0
BlueField3(rev:1) /dev/mst/mt41692_pciconf0.1 0006:03:00.1 mlx5_3 net-bond0 0
BlueField3(rev:1) /dev/mst/mt41692_pciconf1 0016:03:00.0 mlx5_6 net-enP22p3s0f0np0 1
BlueField3(rev:1) /dev/mst/mt41692_pciconf1.1 0016:03:00.1 mlx5_7 net-bond0 1
GB100(rev:0) /dev/mst/mt10561_pciconf0 0008:01:00.0 0
GB100(rev:0) /dev/mst/mt10561_pci_cr0 0008:01:00.0 0
GB100(rev:0) /dev/mst/mt10561_pciconf1 0009:01:00.0 0
GB100(rev:0) /dev/mst/mt10561_pci_cr1 0009:01:00.0 0
GB100(rev:0) /dev/mst/mt10561_pciconf2 0018:01:00.0 1
GB100(rev:0) /dev/mst/mt10561_pci_cr2 0018:01:00.0 1
GB100(rev:0) /dev/mst/mt10561_pciconf3 0019:01:00.0 1
GB100(rev:0) /dev/mst/mt10561_pci_cr3 0019:01:00.0 1
示例中 mlx5_0 的 PCI ID 为 0000:03:00.0。
4.4 查询厂商/设备 ID
根据上一步获取到的 PCI ID 查询：
lspci -n | grep 0000:03:00.0
0000:03:00.0 0207: 15b3:1021
15b3：Mellanox/NVIDIA 厂商 ID1021：具体设备 ID
这里可以获取到配置中需要的 vendors、deviceIDs 参数。
4.5 生成 selectors
汇总以上信息即可写出 selectors，示例如下（可配置多块网卡）：
apiVersion: v1
kind: ConfigMap
metadata:
name: rdma-devices
namespace: kube-system
data:
config.json: |
{
"periodicUpdateInterval": 300,
"configList": [
{
"resourceName": "hca_shared_devices_a",
"rdmaHcaMax": 1000,
"selectors": {
"vendors": ["15b3"],
"deviceIDs": ["1021"],
"ifNames": ["ibp3s0"]
}
}
]
}
更新 ConfigMap 后重启 Device Plugin：
kubectl -n kube-system rollout restart ds rdma-shared-dp-ds
5. 验证
5.1 Node 资源验证
kk describe node gb200-pod2-f06-node05 | grep Capacity -A 9
已经能在 Node 上看到 rdma/hca_shared_devices_a 资源了。
5.2 构建测试镜像
基于 Ubuntu 安装 ibv_devices、ibv_devinfo、ibstat、ibstatus 等工具构建一个用于测试的镜像。
FROM ubuntu:22.04
RUN apt-get update && \
apt-get install -y --no-install-recommends \
perftest \
ibverbs-utils \
ibverbs-providers \
libibumad3 \
libibverbs1 \
librdmacm1 \
infiniband-diags \
iproute2 && \
rm -rf /var/lib/apt/lists/*
ENTRYPOINT ["sleep", "infinity"]
构建镜像：
docker build -t rdma-test:v1 .
已经推送到 dockerhub：lixd96/rdma-test:latest[3]
5.3 Pod 申请资源
启动一个 Pod 申请 RDMA 资源：
apiVersion: v1
kind: Pod
metadata:
name: mofed-test-pod
spec:
restartPolicy: OnFailure
containers:
- image: rdma-test:v1
name: mofed-test-ctr
securityContext:
capabilities:
add: ["IPC_LOCK"]
resources:
limits:
rdma/hca_shared_devices_a: 1
command:
- sh
- -c
- |
ls -l /dev/infiniband /sys/class/infiniband /sys/class/net
sleep 1000000
进入 Pod，使用 ibv_devices 和 ibv_devinfo 查看 IB 卡信息：
ibv_devices
ibv_devinfo
可以看到 Pod 内已经识别到 mlx5_0 等 RDMA 设备。
例如：
root@mofed-test-pod:/# ibv_devices
device node GUID
------ ----------------
mlx5_0 7c8c090300c3cfee
root@mofed-test-pod:/# ibv_devinfo
hca_id: mlx5_0
transport: InfiniBand (0)
fw_ver: 28.44.2524
node_guid: 7c8c:0903:00c3:cfee
sys_image_guid: 7c8c:0903:00c3:cfee
vendor_id: 0x02c9
vendor_part_id: 4129
hw_ver: 0x0
board_id: NVD0000000054
phys_port_cnt: 1
port: 1
state: PORT_ACTIVE (4)
max_mtu: 4096 (5)
active_mtu: 4096 (5)
sm_lid: 1
port_lid: 1336
port_lmc: 0x00
link_layer: InfiniBand
5.4 性能验证
为了全面验证 RDMA 的性能，我们需要启动两个 Pod 进行带宽和延迟测试。
Pod 1 (Server)：
apiVersion: v1
kind: Pod
metadata:
name: rdma-server
spec:
restartPolicy: OnFailure
containers:
- image: rdma-test:v1
name: mofed-test-ctr
securityContext:
capabilities:
add: ["IPC_LOCK"]
resources:
limits:
rdma/hca_shared_devices_a: 1
command:
- sh
- -c
- |
ls -l /dev/infiniband /sys/class/infiniband /sys/class/net
sleep 1000000
Pod 2 (Client)：
apiVersion: v1
kind: Pod
metadata:
name: rdma-client
spec:
restartPolicy: OnFailure
containers:
- image: rdma-test:v1
name: mofed-test-ctr
securityContext:
capabilities:
add: ["IPC_LOCK"]
resources:
limits:
rdma/hca_shared_devices_a: 1
command:
- sh
- -c
- |
ls -l /dev/infiniband /sys/class/infiniband /sys/class/net
sleep 1000000
部署后查看 Pod 状态：
rdma-server 1/1 Running 0 7m18s 172.25.114.16 gb200-pod2-f06-node05
rdma-client 1/1 Running 0 5m24s 172.25.114.38 gb200-pod2-f06-node05
5.4.1 带宽测试
使用 ib_write_bw 工具测试 RDMA 带宽性能。
进入 rdma-server 启动 server:
ib_write_bw -d mlx5_0 -i 1
进入 rdma-client 启动 Client：
# 其中 172.25.114.16 为 rdma-server 的 IP
ib_write_bw -d mlx5_0 -i 1 172.25.114.16
结果如下：
root@rdma-server:/# ib_write_bw -d mlx5_0 -i 1
************************************
* Waiting for client to connect... *
************************************
---------------------------------------------------------------------------------------
RDMA_Write BW Test
Dual-port : OFF Device : mlx5_0
Number of qps : 1 Transport type : IB
Connection type : RC Using SRQ : OFF
PCIe relax order: ON
ibv_wr* API : ON
CQ Moderation : 1
Mtu : 4096[B]
Link type : IB
Max inline data : 0[B]
rdma_cm QPs : OFF
Data ex. method : Ethernet
---------------------------------------------------------------------------------------
local address: LID 0x538 QPN 0x0171 PSN 0x7ef7d8 RKey 0x1fff00 VAddr 0x00aaaaaab00000
remote address: LID 0x451 QPN 0x0165 PSN 0xac1c4 RKey 0x1fff00 VAddr 0x00aaaaaab80000
---------------------------------------------------------------------------------------
#bytes #iterations BW peak[MB/sec] BW average[MB/sec] MsgRate[Mpps]
65536 5000 46711.55 45733.81 0.731741
---------------------------------------------------------------------------------------
测试结果为 46 GB/s 带宽，IB 卡为 400Gb/s，理论带宽为 50GB/s，该结果已经接近 IB 带宽上限，说明 RDMA 已能正常使用。
root@rdma-server:/# ibstat
CA 'mlx5_0'
CA type: MT4129
Number of ports: 1
Firmware version: 28.44.2524
Hardware version: 0
Node GUID: 0x7c8c090300c3a7ae
System image GUID: 0x7c8c090300c3a7ae
Port 1:
State: Active
Physical state: LinkUp
Rate: 400
Base lid: 1105
LMC: 0
SM lid: 1
Capability mask: 0xa751e848
Port GUID: 0x7c8c090300c3a7ae
Link layer: InfiniBand
5.4.2 延迟测试
除了带宽，延迟也是 RDMA 的重要性能指标。使用 ib_write_lat 测试延迟：
在 rdma-server 中启动：
ib_write_lat -d mlx5_0 -i 1
在 rdma-client 中连接：
ib_write_lat -d mlx5_0 -i 1 172.25.114.16
测试结果示例：
---------------------------------------------------------------------------------------
RDMA_Write Latency Test
Dual-port : OFF Device : mlx5_0
Number of qps : 1 Transport type : IB
Connection type : RC Using SRQ : OFF
PCIe relax order: OFF
ibv_wr* API : ON
TX depth : 1
Mtu : 4096[B]
Link type : IB
Max inline data : 220[B]
rdma_cm QPs : OFF
Data ex. method : Ethernet
---------------------------------------------------------------------------------------
local address: LID 0x451 QPN 0x0167 PSN 0xca7dd8 RKey 0x1ffbba VAddr 0x00aaaaaab00000
remote address: LID 0x538 QPN 0x0173 PSN 0x66403f RKey 0x1fecab VAddr 0x00aaaaaab00000
---------------------------------------------------------------------------------------
#bytes #iterations t_min[usec] t_max[usec] t_typical[usec] t_avg[usec] t_stdev[usec]
2 100 2.62 3.84 2.74 2.73 0.04
测试结果显示，RDMA 的单向延迟约为 2.73 微秒，相比传统 TCP/IP 网络（通常 50-100 微秒），延迟降低了 20-40 倍。同时标准差仅为 0.04 微秒，说明延迟非常稳定，充分体现了 RDMA 的低延迟优势。
6. 是否需要 Multus CNI?
在 Kubernetes RDMA 方案中，是否引入 Multus CNI[4] 取决于具体的应用场景和网络需求。
6.1 不需要 Multus CNI 的场景
如果你的需求满足以下条件，通常不需要 Multus CNI：
- 仅需要 IB Verbs API：应用（如 vLLM、NCCL）直接调用 RDMA 接口，不依赖 IP 协议进行通信（或者仅用于控制面）。
- 使用 Shared Device Plugin：本文介绍的
k8s-rdma-shared-dev-plugin 可以在不改变 Pod 网络命名空间结构的情况下，将 RDMA 设备文件（/dev/infiniband/*）暴露给 Pod。
- 扁平网络架构：RDMA 网卡和 Kubernetes 管理网卡处于同一网络平面，或者你能够接受 Pod 沿用 Host 网络的部分特性。
在这种模式下，Pod 依然使用默认 CNI（如 Calico、Flannel）分配的 IP 进行常规通信，同时拥有了访问 RDMA 硬件的能力。这是最简单、运维成本最低的方案。
6.2 需要 Multus CNI 的场景
如果存在以下需求，则建议引入 Multus CNI：
- 网络隔离：需要将 RDMA 流量与 Kubernetes 管理/业务流量完全物理隔离。
- 独立 IP 地址：需要为 RDMA 网卡分配独立的 IP 地址（例如使用 IPoIB 或 RoCEv2 路由模式），以便应用通过特定 IP 进行绑定。
- SR-IOV 场景：如果使用
sriov-cni 将物理网卡虚拟化为 VF 直接透传给 Pod，通常需要 Multus 来管理这个额外的网络接口。
6.3 结论
对于大多数基于 k8s-rdma-shared-dev-plugin 的分布式推理和训练任务，不需要 额外部署 Multus CNI。直接通过 Device Plugin 暴露设备，配合应用层的 RDMA 库即可实现高性能通信。引入 Multus 会显著增加网络配置的复杂度，应仅在确有必要（如强隔离、SR-IOV）时使用。
7. 小结
本文系统性地梳理了在 Kubernetes 集群中落地 RDMA 技术的完整路径。从基础概念的认知，到硬件环境的准备，再到 Device Plugin 的部署与配置，最后通过实际的性能压测验证了 RDMA 性能的优越性。
核心要点回顾：
- 技术价值：RDMA 通过零拷贝和内核旁路技术，解决了 TCP/IP 网络在高带宽场景下的 CPU 瓶颈和延迟问题，是释放 GPU 集群算力的关键基础设施。
- 部署策略：对于大多数 AI 推理和训练场景，使用
k8s-rdma-shared-dev-plugin 配合 Shared 模式是最轻量级的方案。它无需复杂的网络改造，即可让 Pod 获得原生 RDMA 能力。
- 架构决策：在引入 Multus CNI 之前应审慎评估。如果不需要物理隔离或独立 IP，直接复用 Host 网络栈（通过 Device Plugin 暴露设备）往往能带来更低的操作复杂度和更高的稳定性。
随着云原生 AI 的持续演进，底层网络设施的性能优化将变得愈发重要。掌握 RDMA 在 Kubernetes 中的配置与管理，将成为构建高性能 AI 平台的必备技能。未来，我们还可以进一步探索 GPUDirect RDMA、SR-IOV 等进阶技术，以应对更大规模、更低延迟的计算挑战。欢迎到 云栈社区 与更多技术同行交流探讨。
参考资料
[1] k8s-rdma-shared-device-plugin: https://github.com/Mellanox/k8s-rdma-shared-dev-plugin
[2] configmap.yaml: https://github.com/Mellanox/k8s-rdma-shared-dev-plugin/blob/master/deployment/k8s/base/configmap.yaml
[3] lixd96/rdma-test:latest: https://hub.docker.com/r/lixd96/rdma-test/tags
[4] Multus CNI: https://github.com/k8snetworkplumbingwg/multus-cni
发表于 5 天前
|
查看: 21|
回复: 0
