目录
Please enable Javascript to view the contents

K8s网络-AI时代的网络演进

 ·  ☕ 5 分钟

系列导航

本系列从 Pod 网络连通入手，逐步展开到 K8s 网络全景。

① 概念 → ② Flannel → ③ Calico → ④ 流量路径 → ⑤ Cilium → ⑥ 对比 → ⑦ 排障 ‖ ⑧ 开发 → ⑨ 多网卡 → ⑩ AI 演进

顺序文章定位
①概念与入门基础——主机网络、Docker 网络、CNI 标准、方案分类树
②Flannel 详解CNI 实现——Overlay 封装（UDP/VXLAN/HostGW）与抓包
③Calico 详解CNI 实现——三层路由（BGP/IPIP）+ NetworkPolicy
④流量路径全解析全貌——Pod/Service/Ingress/Egress，揭示 CNI 的边界
⑤Cilium 详解超越 CNI——eBPF 统一 Pod + Service + L7 + Hubble
⑥插件对比与选型选型——5 插件横向对比 + 决策树
⑦排障思路与常用命令运维——工具链 + 场景排查 + 性能
—核心路径 ↑扩展展望 ↓
⑧CNI 插件开发指南扩展——基于 CNI 规范开发自定义插件
⑨多网卡方案详解进阶——Multus + SR-IOV/ipvlan 多网口实战
⑩本篇 - AI 时代网络演进展望——GPU 网络、eBPF 加速、未来方向

重要

GPU 分布式训练需求的爆发，推动 CNI 领域从"Pod 互通"向"微秒级延迟、百GB吞吐"演进。以下按变化方向、技术方案、适用场景整理。

1. GPU 直通网络（RDMA / RoCE）

分布式训练的开销不在计算，在 GPU 之间的梯度同步通信（all-reduce）。传统内核协议栈（TCP/IP）延迟在 50μs-200μs 级别，对于千卡并行训练来说不可接受。

技术原理延迟吞吐CNI 实现
RDMAInfiniBand 网卡，用户态直接访问远端内存，绕过内核< 2μs200Gbps+ib-kubernetes、Network Operator
RoCE v2融合以太网跑 RDMA，UDP 封装，需要 PFC/ECN 保证无损~5μs100GbpsMultus + SR-IOV + whereabouts IPAM
GPUDirect RDMAGPU 显存 ↔ 网卡直接 DMA，不经过 CPU 内存< 1μs400Gbps需 NVIDIA Network Operator

关键变化： 这类 Pod 不经过 CNI 的内核网络栈（veth/bridge/iptables），而是通过 SR-IOV 拿到 VF（虚拟物理网卡），直接接入 RDMA 网络。CNI 只负责分配 VF 和 IP。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# Multus + SR-IOV 示例：Pod 拿到两张网卡
# eth0: Cilium/Flannel 管理的管理面
# net1: SR-IOV VF 直接接入 RDMA 网络
apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/networks: '[
      {"name":"sriov-rdma","interface":"net1"}
    ]'
spec:
  containers:
  - name: training
    resources:
      limits:
        nvidia.com/gpu: 8

2. eBPF 数据路径加速

传统 K8S 网络路径中，iptables 规则链遍历是主要性能瓶颈。Service 数量 >1000 时，每个新连接都要遍历完整链才能找到匹配规则，延迟分布出现长尾。

对比维度iptables（kube-proxy）Cilium eBPF
Service 匹配O(n) 线性遍历O(1) eBPF Map 哈希查找
连接跟踪Linux conntrack（全局锁）独立 eBPF conntrack
包在宿主机路径veth → bridge → iptables（多轮 Netfilter 钩子）veth → TC eBPF（单轮）
延迟分布长尾（P99 可达数十ms）稳定（P99 接近 P50）

AI 场景为什么更需要 eBPF？ 分布式训练的 all-reduce 流量是 burst 型的——同步时瞬间涌出大量连接，iptables 在并发连接建立时延迟尖峰尤为突出。Cilium 用 eBPF 替代后，Service 访问延迟均值从 ~1ms 降到 ~0.2ms，P99 降幅更大。

3. 多网卡场景

AI 训练节点通常配备双网卡：一个低速管理面（eth0），一个高速 RDMA 面（eth1/ib0）。需要 CNI 支持多网络接口。

组件作用管理网络
Multus多网卡 CNI 调度器——给 Pod 分配多张网卡委托其他 CNI 插件为每张网卡分配 IP
Cilium/Flannel管理面网络（Pod 互通、DNS、Pull 镜像）eth0
SR-IOV / ipvlanRDMA 高速面（GPU 间通信）eth1 / ib0
1
2
3
4

# 查看 Pod 多网卡
[root@node1 ~]# kubectl exec gpu-pod -- ip a
3: eth0: <BROADCAST> inet 10.244.1.5/32    # Cilium 管理面
4: net1: <BROADCAST> inet 192.168.100.5/24 # SR-IOV RDMA 面

4. Gateway API 取代 Ingress

K8S 社区从 Ingress v1 向 Gateway API 迁移，对 CNI 的影响是——Ingress Controller 不再是独立 Sidecar，可以集成到 CNI 的数据路径中。

对比IngressGateway API
标准化K8S v1.19 GA，功能简单（L7 HTTP 路由）v1.0 2023.10 GA，支持 L4/L7、TLS、跨命名空间
实现耦合独立 Ingress Controller（nginx/traefik）可集成进 CNI 数据路径（Cilium 已支持）
流量路径客户端 → Ingress Controller Pod → Service → Pod（多一跳）客户端 → eBPF L7 代理 → Pod（少一跳）
Cilium 支持不直接支持 Ingress原生支持 Gateway API（Cilium 1.14+）
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# Cilium 原生 Gateway API 示例
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cilium-gw
spec:
  gatewayClassName: cilium
  listeners:
  - name: http
    port: 80
    protocol: HTTP
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
spec:
  parentRefs:
  - name: cilium-gw
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: backend-svc
      port: 8080

5. 总结

CNI 领域最近两年的演进方向：从 Pod 互通向端到端可编程数据路径演进。

方向之前现在
数据路径内核协议栈（TCP/IP）RDMA 绕过内核 + eBPF 在内核编程
Servicekube-proxy + iptableseBPF 替代 kube-proxy
Ingress独立 Ingress ControllerGateway API 集成进 CNI 数据路径
网络策略iptables L3/L4eBPF L3/L4/L7
网卡数量单网卡Multus 多网卡标配
可观测性tcpdump / netstatHubble / eBPF 原生指标

6. 当前未解决的问题

尽管演进很快，以下几个问题在生产落地中仍缺乏成熟方案：

问题现状影响
GPU 网络多租户隔离SR-IOV VF 直通后，VF 之间的流量不经过内核，无法用 Netfilter/eBPF 做策略不同租户的 GPU Pod 可能意外互通，安全边界模糊
RDMA 与 K8S QoS 脱节K8S 的 CPU/内存 QoS（Guaranteed/Burstable）无法延伸到 RDMA 网络带宽控制一个 Pod 的 all-reduce 流量可能占满 RoCE 链路，影响邻居 Pod
eBPF 调试门槛高Cilium 数据路径出错时，传统工具（tcpdump/ss/netstat）看不到 eBPF Map 内部状态排障需要 cilium monitor、bpftool 等专用工具，学习曲线陡峭
多 CNI 组合排障困难Multus + Cilium + SR-IOV 三层组合，任一环节配置错误都表现为 Pod 不通排查需要同时理解三个 CNI 的配置格式和调用顺序
Gateway API 生态未成熟2024 年虽已 GA，但大部分入口控制器（nginx/traefik）仍以 Ingress 为主，迁移路径长生产环境同时维护 Ingress + Gateway API 两套配置

7. 下一步方向

方向说明预计成熟时间
DPU/SmartNIC 卸载将 CNI 数据路径（veth、路由、隧道封装）卸载到智能网卡硬件，宿主机 CPU 零消耗2-3 年（NVIDIA BlueField/Intel IPU 已在试点）
eBPF 替代更多内核子系统Cilium 已替换 kube-proxy，下一步目标：替换 conntrack、替换 netfilter 全部钩子1-2 年（Cilium 1.16+ 计划）
CNI-GPU 联合调度K8S 调度器感知 GPU 拓扑（NVLink/NVSwitch）和网络拓扑，Pod 被调度到同机架以减少跨机通信1-2 年（Kueue/Volcano 已有原型）
标准化的高性能 CNI APICNCF 社区讨论将 SR-IOV、RDMA 分配标准化为 CNI 规范的扩展，不再依赖厂商插件2-3 年
AI 训练网络可观测性在 all-reduce 通信路径上埋点，监控 GPU 间通信带宽、延迟、重传，对训练效率建模1 年（NVIDIA NSight/Grafana 已有集成）

参考链接

分享
Hex
作者
Hex
CloudNative Developer

相关内容