引言：当容器的“软桥”成为性能瓶颈

在裸金属物理机上跑Docker，很多人以为“没有Hypervisor层开销，网络性能就完美了”——这是个笑话。Docker默认的bridge模式通过iptables NAT + veth pair转发，单核吞吐量在64字节小包场景下直接腰斩。底层原理是：每个网络包要经过两次内核协议栈（容器netns -> 宿主机bridge -> 物理网卡），加上conntrack跟踪，延迟增加30-50μs。

真正的性能杀手在于：中断处理和内存拷贝。普通容器网络栈把物理网卡的中断绑定到宿主机CPU，再把数据从内核态拷贝到容器内存，CPU cache打翻，NUMA远端访问又添乱。本文直接撕开Docker网络的血肉，用SR-IOV硬件直通把整个协议栈踢到用户态，让容器如同直接操作网卡。

1. SR-IOV：物理网卡的“分身术”

SR-IOV允许单张PCIe网卡暴露多个虚拟功能（VF），每个VF拥有独立的队列、中断和DMA能力。在裸金属上，宿主机内核只需管理一个物理功能（PF），容器可直接绑定VF，绕过宿主机协议栈。关键在于：VF通过硬件IOMMU映射到容器进程的地址空间，零拷贝。

# 查看网卡是否支持SR-IOV
lspci -vvv | grep -i 'SR-IOV'
# 启用VF数量（以Mellanox ConnectX-5为例）
echo 4 > /sys/class/net/eth0/device/sriov_numvfs
# 确认VF生成
ip link show | grep vf

但别急着高兴——VF的MAC地址和VLAN必须提前配好，否则容器内看不到链路。实战踩坑记录：某次在轻云互联的裸金属实例上，忘记给VF设置随机MAC，导致容器内DHCP一直拿不到IP，最后手动写死解决。

# 设置VF的MAC和VLAN
ip link set eth0 vf 0 mac 02:00:00:00:00:01
ip link set eth0 vf 0 vlan 100

2. Docker直连VF：告别veth与bridge

Docker本身不直接管理VF，但可以通过--device参数把VF设备文件挂进容器。此时容器内需要用户态驱动（如DPDK或普通内核驱动）。这里用最直接的方式：让容器内使用标准内核驱动认领VF，配合ip netns手动将VF移入容器网络命名空间。

2.1 手动绑定VF到容器

# 创建容器但不启动网络
docker run -itd --net=none --name=perf-test alpine:latest
# 获取容器PID
PID=$(docker inspect --format='{{.State.Pid}}' perf-test)
# 创建netns软链接
mkdir -p /var/run/netns
ln -sf /proc/$PID/ns/net /var/run/netns/$PID
# 将VF移动到容器netns
ip link set eth0 vf 0 mac 02:00:00:00:00:01
ip link set eth0 vf 0 trust on  # 允许VF执行特权操作（如混杂模式）
ip link set eth0 vf 0 state auto
# 将VF设备（例如enp4s0f0v0）移动到容器
ip link set enp4s0f0v0 netns $PID
# 在容器netns内部配置IP
ip netns exec $PID ip addr add 192.168.1.10/24 dev enp4s0f0v0
ip netns exec $PID ip link set enp4s0f0v0 up

优点：容器获得完全独立的网卡队列，中断直接发到容器内CPU核心。缺点：每次容器重启需要重新操作。更优雅的方案是用SR-IOV CNI插件（如Kubernetes环境），但裸金属单机场景下上述脚本更可控。

3. 性能差距：从数据面看本质

我们拿同样的裸金属硬件（Intel Xeon 6248 + Mellanox ConnectX-5 25Gbps）对比三种模式：

• Bridge模式：Docker默认
• Macvlan模式：直接绑定物理网卡子接口（需混杂模式）
• SR-IOV直通：VF直接分配给容器

# 使用iperf3测试吞吐（TCP）
# Bridge模式结果：
[  3]  0.00-30.00 sec  5.43 GBytes  1.56 Gbits/sec
# Macvlan模式结果：
[  3]  0.00-30.00 sec  9.21 GBytes  2.64 Gbits/sec
# SR-IOV直通结果：
[  3]  0.00-30.00 sec  17.8 GBytes  5.10 Gbits/sec

关键差异在CPU占用率：Bridge模式下单核跑满约80%，SR-IOV仅25%。原因是VF在硬件层面完成了数据分发，内核只做极简的ring buffer管理。若搭配DPDK用户态驱动，小包PPS甚至可以突破2000万。

4. 调优进阶：NUMA亲和性与中断隔离

裸金属的优势在于硬件拓扑透明。VF与PCIe插槽绑定，必须将容器CPU绑定到同一NUMA节点，否则跨NUMA访问内存，延迟翻倍。

# 查看VF所在NUMA节点
cat /sys/class/net/enp4s0f0v0/device/numa_node
# 返回0，则需将容器绑定到NUMA0的CPU
# Docker启动参数：
--cpuset-cpus="0-3" --cpuset-mems="0"
# 以及设置中断亲和性：
echo 0f > /proc/irq/$(cat /sys/class/net/enp4s0f0v0/device/msi_irqs)/smp_affinity

排错命令：mpstat -P ALL 1观察中断是否集中到目标核心。如果发现IRQ均衡器把中断打散，关掉irqbalance服务。

5. 生产环境踩坑：VF的“孤儿”状态

有一次我在轻云互联的裸金属上测试，重启宿主机后VF设备消失，但/SRV/IOV数量已固化到BIOS。排查发现是pci-stub模块冲突，导致VF驱动没有加载。修复方案：

# 确保VF驱动在initramfs中
echo "mlx5_core" >> /etc/initramfs-tools/modules
update-initramfs -u
# 强制重新绑定
echo "0000:04:00.0" > /sys/bus/pci/drivers/mlx5_core/unbind
echo "0000:04:00.0" > /sys/bus/pci/drivers/mlx5_core/bind

另外，若容器内使用普通驱动而不是DPDK，必须确保内核开启CONFIG_PCI_IOV和IOMMU。通过dmesg | grep -i iommu检查。

总结

裸金属+Docker的终极网络形态就是硬件直通+用户态驱动。SR-IOV是当前性价比最高的实现——不需要昂贵的SmartNIC，普通25G/100G网卡即可。当你的容器需要处理千万级PPS、毫秒级业务时，别再看bridge那点花活，直接抢过网卡的DMA引擎，让内核当旁观者。