在 AI 时代，容器网络的性能成为制约大规模 AI 工作负载的关键因素。传统上，容器网络依赖 veth（Virtual Ethernet）设备，但随着容器规模的增长，veth 的局限性日益明显。本文聚焦 Linux 内核中的 netkit 设备，以及 Cilium 如何把它作为新的 Pod 设备模式来降低 datapath 开销。
## 背景：veth 的局限性
在深入了解 Netkit 之前，我们需要理解当前容器网络的核心问题。
### 网络命名空间与 veth
Kubernetes 中，每个 Pod 运行在独立的网络命名空间（Network Namespace）中。这种隔离机制虽然提供了安全性和灵活性，但也带来了显著的性能开销。
```mermaid
graph LR
subgraph "Pod 命名空间"
A[Container]
end
subgraph "Host 命名空间"
B[veth peer]
C[Host Networking
Cilium Datapath]
D[Host Network]
end
A -->|veth pair| B
B --> C
C --> D
```
**veth 的工作原理：**
- veth 设备自 2008 年引入 Linux 内核
- 创建一对虚拟以太网设备，一端在容器内，一端在宿主机上
- 数据包在容器和宿主机之间传输时，需要跨越网络命名空间边界
- 每次命名空间切换都涉及上下文切换和内核处理开销
### veth 的性能瓶颈
根据 Cilium 官方文档和 FOSDEM 2025 的公开分享，veth 在大规模容器场景下主要有以下问题：
1. **命名空间切换开销**：数据包从容器到宿主机需要穿越命名空间边界
2. **内核网络栈处理**：数据包经过多个队列和上下文切换
3. **BPF 程序管理的复杂性**：在 veth 上附加 BPF 程序需要针对 peer 设备单独管理
4. **有限的 eBPF 可编程性**：veth 并非为 eBPF 原生设计
## Netkit 简介
### 什么是 Netkit
Netkit 是一种 **BPF 可编程的网络设备**（BPF Programmable Network Device），它专为容器网络场景设计。netkit 设备在 **Linux 内核 6.7** 中引入；但如果你关注的是 **Cilium 的 netkit datapath mode**，官方要求的内核版本是 **6.8 及以上**。
> 注意：不要将 Netkit 与早期的 Netkit（用于在单台服务器上创建虚拟网络的项目，已停止维护）混淆。
### Netkit 的核心特性
```mermaid
graph TB
subgraph "Netkit 设备"
A[Netdev
主设备]
B[Netdev
对端设备]
end
subgraph "BPF Integration"
C[Pod BPF Programs]
D[TCX Attachments]
E[eBPF Host-Routing]
end
A --> C
A --> D
A --> E
A <-->|peer| B
```
**关键特性：**
1. **面向容器场景设计**：netkit 不是通用虚拟网卡的简单替代，而是围绕容器 datapath 设计
2. **更适合与 Cilium 的 BPF datapath 配合**：Pod 侧 BPF 程序可以挂到 netkit peer device 上
3. **TCX 支持**：Cilium 在启用 netkit 时也会在其他非 netkit 设备上使用 tcx attachment
4. **更低的 datapath 开销**：配合 eBPF host-routing，可减少传统 veth 路径中的额外处理
## 技术原理：Netkit vs veth
### veth 的数据包流程
使用 veth 时，数据包从容器到外部网络的路径如下：
```
Container → veth pair → Network Namespace Switch → Host Stack → External
```
每个步骤都涉及：
- 上下文切换
- 队列排队
- 内核处理延迟
### Netkit 的数据包流程
Netkit 优化了这一流程：
```
Container → netkit device → Pod BPF Program → eBPF Host-Routing → External
```
通过 eBPF Host-Routing 和 netkit 的组合，数据包可以：
- 绕过部分宿主机上层网络栈
- 减少传统 veth 模式下的额外 datapath 开销
- 在 off-node ingress / egress 场景下实现更快的网络命名空间切换
### netkit 与 tcx 的关系
```mermaid
sequenceDiagram
participant C as Container
participant N as Netkit Peer
participant BPF as Pod BPF Program
participant H as Host Stack
C->>N: 数据包入站
N->>BPF: BPF 程序触发
BPF->>BPF: 策略检查/转发决策
alt 直接转发
BPF->>H: Host-Routing Fast Path
else 需要处理
BPF->>N: 注入处理
N->>H: 完整处理
end
```
官方文档里，Cilium 对 netkit 的描述重点有两点：
1. **Pod BPF 程序挂载位置变化**：Pod 相关 BPF 程序挂在 netkit peer device 上，并且只能从 host namespace 管理
2. **tcx attachment 一并启用**：开启 netkit 后，Cilium 也会在非 netkit 设备上使用 tcx，以获得更高效的 attachment 方式
## 性能提升
### 基准测试结果
公开资料普遍给出的结论是：**netkit 的收益主要体现在降低延迟和减少 datapath 开销**，但提升幅度与 workload、内核版本、是否启用 eBPF host-routing 等因素强相关，因此不宜脱离测试上下文直接给出统一数字。
例如，Meta 在 FOSDEM 2025 的分享中给出的一个案例是：同机 4 份副本叠加运行时，P99 延迟曾因 SoftIRQ 压力超过 12 秒；启用 netkit 后，P99 延迟下降到约 100ms。这个数字很亮眼，但它描述的是**特定场景下的实测结果**，不应直接外推到所有环境。
### ByteDance 的实践
字节跳动（ByteDance）是 netkit 技术的早期采用者之一。公开报道显示，他们正在面向**百万级容器规模**推进这项技术，并已在多个集群中落地验证。
> "设置 veth 和 netkit 没有太大区别，但要达到最佳性能，eBPF 程序需要针对 netkit 进行优化。" —— The New Stack 报道
**从公开材料看，字节跳动关注的重点包括：**
1. **大规模部署验证**：逐步验证 netkit 在大规模容器场景下的稳定性
2. **内核能力补齐**：他们分享过在较老内核上回补相关能力的实践
3. **CNI / eBPF 适配**：为了发挥 netkit 的收益，需要配套更新 CNI 和 BPF 程序
### Meta 的贡献
Meta 的工程师也在积极推动 Netkit 的发展：
- 在 FOSDEM 2025 上分享了 Netkit 的实践经验
- 优化 Meta 容器平台的网络性能
- 推动 Netkit 在云原生生态中的 adoption
## Cilium 集成
### Cilium 1.16+ 的 netkit 支持
Cilium 1.16 开始支持把 netkit 作为新的 datapath mode 使用，但它默认仍然使用 veth。
**配置方式：**
```bash
helm upgrade cilium cilium/cilium \
--namespace kube-system \
--reuse-values \
--set routingMode=native \
--set bpf.datapathMode=netkit \
--set bpf.masquerade=true \
--set kubeProxyReplacement=true
```
如果你要按节点逐步灰度，也可以使用 `CiliumNodeConfig` 覆盖对应 agent 配置；但本质上仍然是覆盖 `bpf.datapathMode` 等参数，而不是单独写一个 `netkit.enabled=true` 开关。
### 自动检测与回退
Cilium 对 netkit 的行为要分两种情况理解：
- **`bpf.datapathMode=netkit`**：如果内核或依赖能力不满足要求，Cilium 会启动失败，而不是自动回退
- **`bpf.datapathMode=auto`**：只有在这个模式下，Cilium 才会在运行时检测是否支持 netkit，支持则使用 netkit，否则回退到 veth
### 性能调优建议
```bash
# 检查当前 Device Mode
cilium status
# 或在 Cilium Pod 内检查关键状态
kubectl -n kube-system exec -c cilium-agent -- cilium status
```
需要重点确认两项：
- `Device Mode` 是否为 `netkit`
- `Host Routing` 是否为 `BPF`
**最佳实践：**
1. **区分内核引入版本与 Cilium 要求版本**：Linux netkit 是 6.7 引入，但 Cilium 官方要求 netkit mode 使用 **6.8+**
2. **配合 eBPF Host-Routing 使用**：这是官方强调的前提条件之一
3. **按节点灰度，而不是原地替换**：官方明确说明，已有 veth Pod 的集群不能直接 in-place 切到 netkit
4. **启用 kubeProxyReplacement 与 BPF masquerade**：这是官方示例中的推荐组合
## 未来展望
### 云原生网络的演进
netkit 代表了容器网络技术的一个重要演进方向：
1. **从通用到专用**：从通用的 veth 到专为容器设计的 Netkit
2. **eBPF 原生**：从附加 eBPF 程序到原生 eBPF 集成
3. **性能优先**：在保证安全性和功能性的同时追求极致性能
### 生态发展
- **更多 CNI 插件**：预计更多 CNI 插件会逐步评估 netkit 的适配价值
- **硬件加速**：Netkit 的架构更适合与硬件加速器集成
- **AI 工作负载优化**：针对 AI/ML 工作负载的网络需求进行专门优化
### Cilium 的持续创新
作为 eBPF 和云原生网络的领导者，Cilium 将继续推动 Netkit 的发展：
- 更好的性能优化
- 更易用的配置
- 更广泛的硬件支持
## 总结
netkit 代表了容器网络设备设计的一次重要演进。对 Cilium 用户来说，它的价值不只是“换一种 Pod 网卡”，而是和 eBPF host-routing、tcx attachment 等能力一起，尽量减少传统 veth 模式里的额外 datapath 开销。
**关键要点：**
- netkit 设备在 Linux 内核 6.7 引入，但 Cilium 官方要求 netkit datapath mode 使用 6.8+ 内核
- Cilium 1.16+ 已支持 netkit datapath mode，不过默认仍然是 veth
- netkit 通常需要和 eBPF host-routing 组合使用，收益主要体现在降低延迟和减少 datapath 开销
- `bpf.datapathMode=netkit` 不会自动回退；只有 `auto` 模式才会在支持时启用 netkit、否则回退到 veth
- 已有 veth Pod 的集群不能直接原地切换到 netkit，更适合按节点灰度迁移
随着 AI 工作负载的持续增长和对更高网络性能的追求，netkit 很可能会在云原生网络里扮演越来越重要的角色，但它更适合被理解为一项需要结合内核版本、Cilium 配置和迁移策略来整体评估的能力，而不是一个单独打开即可获益的“开关”。
---
**参考资料：**
- [Cilium 官方文档：Netkit device mode](https://docs.cilium.io/en/stable/operations/performance/tuning/)
- [Cilium 官方文档：Per-node configuration](https://docs.cilium.io/en/stable/configuration/per-node-config.html)
- [Cilium 官方文档：System requirements](https://docs.cilium.io/en/latest/operations/system_requirements.html)
- [FOSDEM 2025: An Introduction to Netkit](https://archive.fosdem.org/2025/schedule/event/fosdem-2025-4045-an-introduction-to-netkit-the-bpf-programmable-network-device/)
- [Netkit to Network a Million Containers for ByteDance](https://thenewstack.io/bytedance-to-network-a-million-containers-with-netkit/)