Kubernetes CNI 选型AI 集群网络不要照搬 Web 服务方案一、AI 集群网络不是 Web 集群的放大版流量模式的根本差异Web 服务集群的流量特征已经被充分理解南北向流量为主东西向以微服务 RPC 调用为补充单次请求数据量小通常 KB 级别连接数以千计。CNI 选型上Flannel VXLAN 或 Calico IPIP 基本够用——多几十微秒的封装延迟对 HTTP 响应时间几乎没有影响。AI 集群完全是另一回事。一次分布式训练中AllReduce 通信产生的网络流量可以超过 100 Gbps单次 NCCL 集合通信操作的延迟要求通常是微秒级。更关键的是通信模式不是随机的点对点通信而是固定的全对全All-to-All模式N 个 GPU 之间需要同时交换梯度数据。如果直接把 Web 集群的 Flannel VXLAN 方案迁移到 AI 集群会发生什么VXLAN 封装会增加约 50 字节的包头对 Web 请求微不足道但对 GPU 之间传输的 4MB 梯度张量来说封装开销可以忽略。真正的问题是路径VXLAN 模式下数据包必须经过宿主机的内核网络栈——iptables 规则匹配、conntrack 表查询、netfilter 钩子执行——每一步都增加数十微秒的延迟。对 NCCL Ring AllReduce 而言端到端延迟 max(所有参与 Rank 的单步延迟)。每微秒的累积最终转化为训练步数的可见下降。基础设施不需要漂亮话。选错 CNI每步训练多花 200 微秒100 万步下来就是额外的 200 秒换算成 GPU 成本是实实在在的账单数字。二、CNI 数据路径对比VXLAN 隧道 vs 主机路由 vs SR-IOV不同的 CNI 方案在数据路径上存在本质差异。下图展示了三种典型架构中数据包从 Pod A 到 Pod B 的传输路径graph TD subgraph VXLAN[Flannel VXLAN 路径] A1[Pod A eth0] -- A2[veth pair] A2 -- A3[cni0 bridge] A3 -- A4[iptables/conntrack] A4 -- A5[flannel.1 VTEP] A5 -- A6[host eth0] A6 -- A7[物理网络] A7 -- B6[host eth0] B6 -- B5[flannel.1 VTEP] B5 -- B4[iptables/conntrack] B4 -- B3[cni0 bridge] B3 -- B2[veth pair] B2 -- B1[Pod B eth0] end subgraph Calico[Calico 主机路由路径] C1[Pod A eth0] -- C2[veth pair] C2 -- C3[内核路由表br/直查下一跳] C3 -- C4[host eth0] C4 -- C5[物理网络] C5 -- D4[host eth0] D4 -- D3[内核路由表] D3 -- D2[veth pair] D2 -- D1[Pod B eth0] end subgraph SR-IOV[SR-IOV 路径] E1[Pod A VF 直通] -- E2[host NIC SR-IOV] E2 -- E3[物理网络] E3 -- F2[host NIC SR-IOV] F2 -- F1[Pod B VF 直通] endVXLAN 路径经过 6 个内核处理点veth → bridge → iptables → VTEP → eth0 → 物理每个点都有上下文切换和内存拷贝的开销。Calico 主机路由模式绕过 bridge 和 VTEP直接通过内核路由表完成转发路径缩短为 4 个处理点。SR-IOV 则更进一步通过 PCIe 直通技术Pod 直接操作物理网卡的虚拟功能VF完全旁路内核网络栈路径仅为 3 个硬件节点。在推理服务的 GPU 通信场景中NCCL 对延迟极度敏感。实测数据表明同一台物理机上的 8 卡训练VXLAN 模式下的 NCCL Bus Bandwidth 约为主机路由模式的 85%-90%。跨节点的 AllReduce 差距更大VXLAN 可能只有原生 RDMA 方案的 60% 带宽。三、AI 集群 CNI 配置实践3.1 多网卡平面分离控制面与数据面隔离AI 集群最基础的 CNI 配置是把控制流量和数据流量分开。以下使用 Multus 实现双网卡方案apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: rdma-net namespace: kube-system spec: config: | { cniVersion: 0.3.1, type: host-device, device: ib0, ipam: { type: whereabouts, range: 192.168.100.0/24 } } --- apiVersion: k8s.cni.cncf.io/v1 kind: NetworkAttachmentDefinition metadata: name: mgmt-net namespace: kube-system spec: config: | { cniVersion: 0.3.1, type: macvlan, master: eth0, mode: bridge, ipam: { type: whereabouts, range: 10.244.0.0/16 } }训练 Pod 声明使用双网络apiVersion: v1 kind: Pod metadata: name: train-job-0 annotations: k8s.cni.cncf.io/networks: rdma-net, mgmt-net spec: containers: - name: trainer image: nvcr.io/nvidia/pytorch:24.06-py3 env: - name: NCCL_SOCKET_IFNAME value: net1 # RDMA 网卡用于 NCCL 通信 - name: NCCL_IB_DISABLE value: 0 # 启用 InfiniBand resources: limits: nvidia.com/gpu: 8NCCL_SOCKET_IFNAME环境变量确保所有 GPU 间通信走 RDMA 网卡而不经过管理网络。Whereabouts IPAM 为 RDMA 网络提供静态范围分配避免 DHCP 的间歇性延迟。3.2 Calico eBPF 模式替代 iptablesCalico 从 v3.22 开始支持 eBPF 数据面模式将 Service 转发和网络策略的执行从 iptables 迁移到 eBPF 程序。在 AI 集群中eBPF 模式可以显著减少服务发现的延迟抖动apiVersion: operator.tigera.io/v1 kind: Installation metadata: name: default spec: calicoNetwork: bgp: Enabled linuxDataplane: BPF hostPorts: Enabled --- apiVersion: v1 kind: ConfigMap metadata: name: calico-config namespace: kube-system data: calico_backend: vxlan veth_mtu: 9000关键配置linuxDataplane: BPF将 kube-proxy 的 iptables 规则替换为 eBPF MapService IP 到 Pod IP 的转换从 O(n) 的链式匹配变为 O(1) 的哈希查找。veth_mtu: 9000启用 Jumbo Frame。NCCL 默认使用 4MB 的消息大小分片传输MTU 从 1500 提升到 9000 可以减少约 83% 的分片数量。3.3 主机网络模式当延迟要求极其苛刻时对于延迟要求在微秒级的推理预热阶段模型加载到 GPU 显存的时间直接决定冷启动延迟可以将推理服务 Pod 设置为hostNetwork: true直接使用宿主机网络栈apiVersion: apps/v1 kind: Deployment metadata: name: inference-server spec: template: spec: hostNetwork: true dnsPolicy: ClusterFirstWithHostNet containers: - name: vllm image: vllm/vllm-openai:latest ports: - containerPort: 8000 env: - name: NCCL_DEBUG value: INFO - name: CUDA_VISIBLE_DEVICES value: 0,1,2,3,4,5,6,7使用 hostNetwork 的代价失去了 Pod 之间的网络隔离端口冲突需要人工管理。仅推荐在推理服务天然独占 GPU 节点场景使用训练 Job 仍然建议使用 CNI 网络。四、CNI 方案选择的权衡矩阵没有万能方案CNI 选型始终是性能、可运维性和成本之间的三角平衡。Flannel VXLAN。优势在于零配置、社区最成熟。劣势是内核路径长、不支持 NetworkPolicy。适用场景开发测试集群、小型 GPU 集群≤4 节点、不需要跨节点 NCCL 通信的场景。Calico BGP/路由模式。优势是高性能、原生支持 NetworkPolicy、集群规模可达 5000 节点。劣势是 BGP 协议需要网络团队配合部分云厂商 VPC 不支持 BGP。适用场景中型生产 AI 集群、需要细粒度网络策略。Calico eBPF。优势是极低的 Service 转发延迟、无 iptables 规则爆炸问题。劣势是内核版本要求 ≥5.3推荐 ≥5.10RHEL 8 系列需要额外内核参数。适用场景大规模推理集群、Service 数量超过 1000 的环境。SR-IOV Multus。优势是接近裸金属的网络性能、RDMA 支持。劣势是硬件依赖、运维复杂度高——每个 Pod 需要手动绑定 VF 或依赖 device plugin。适用场景千卡级训练集群、需要 RDMA over Converged Ethernet (RoCE) 的场景。五、总结AI 集群的 CNI 选型不能照搬 Web 服务的经验核心原因是流量模式、延迟敏感度和通信规模的差异。选型决策应遵循以下步骤先确定数据面需求是否需要 RDMA是否需要网络策略Service 数量是否超过 iptables 可承受的上限评估节点规模10 台以内可以使用 Flannel VXLAN 降低运维成本100 台以上必须考虑 Calico BGP 或 eBPF 模式。分离控制面和数据面使用 Multus 为 NCCL 通信分配独立的 RDMA 网卡管理流量仍走默认 CNI。优先配置 Jumbo FrameMTU 9000和 eBPF 模式这两项配置的投入产出比在 AI 集群中最优。选 CNI 不是选最好的是选最匹配集群通信模式的。基础设施不需要漂亮话需要的是在正确的地方投入正确的技术。