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 直通]
    end

VXLAN 路径经过 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: 8

NCCL_SOCKET_IFNAME 环境变量确保所有 GPU 间通信走 RDMA 网卡，而不经过管理网络。Whereabouts IPAM 为 RDMA 网络提供静态范围分配，避免 DHCP 的间歇性延迟。

3.2 Calico eBPF 模式替代 iptables

Calico 从 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 Map，Service 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.10），RHEL 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 Frame（MTU 9000）和 eBPF 模式：这两项配置的投入产出比在 AI 集群中最优。

选 CNI 不是选最好的，是选最匹配集群通信模式的。基础设施不需要漂亮话，需要的是在正确的地方投入正确的技术。

文章版权归作者所有，未经允许请勿转载。

零基础入门：UI-UX Pro Max Skill保姆级教程——让AI成为你的专业设计助手，打造跨平台UI/UX的智能设计引擎

Kubernetes CNI 选型：AI 集群网络不要照搬 Web 服务方案