- BPF 程序的基本开销
Pod veth (xxx_h):
├─ tc ingress: cil_to_container (从 host → Pod)
└─ tc egress: cil_from_container (从 Pod → host)
🎯 Pod veth BPF 程序的性能开销分析
- BPF 程序的执行路径
// 简化的执行流程
cil_from_container(struct __ctx_buff *ctx) {
1. 解析数据包头（Ethernet, IP, L4） // ~50 ns
2. 查找 endpoint identity // ~100 ns (BPF map lookup)
3. 网络策略检查 // 取决于策略数量
- 无策略: ~50 ns (快速跳过)
- 有策略: ~200-500 ns (需要查表)
4. Bandwidth Manager EDT 设置 // ~50 ns
- 无 annotation: 跳过
- 有 annotation: 计算 EDT timestamp
5. 连接跟踪（CT）处理 // ~200-300 ns (CT map lookup)
6. Service 负载均衡（如果启用） // ~300-500 ns
7. 可观测性（Hubble） // ~50-100 ns (如果启用)
8. 数据包转发决策 // ~50 ns
总计（最小配置）: ~500-700 ns/packet
总计（启用所有功能）: ~1500-2000 ns/packet
}
📊 在你的配置下的实际开销
基于你的 cilium-values.yml：
# 你的配置
policyEnforcementMode: default # 网络策略启用
hubble.enabled: false # Hubble 禁用
bandwidthManager.enabled: true # Bandwidth Manager 启用
kubeProxyReplacement: false # Service LB 部分功能
enableIdentityMark: false # Identity Mark 禁用
cni.chainingMode: generic-veth # Chaining 模式
你的环境下，每个数据包的 BPF 开销：
| 功能模块 | 是否启用 | CPU 时间 | 说明 |
|---|---|---|---|
| 数据包解析 | ✅ 总是 | ~50 ns | 必需 |
| Endpoint lookup | ✅ 总是 | ~100 ns | 查找 Pod identity |
| 网络策略检查 | ✅ 如有策略 | ~50-500 ns | 取决于策略复杂度 |
| Bandwidth EDT | ✅ 如有 annotation | ~0-50 ns | 无 annotation 时几乎为 0 |
| 连接跟踪 (CT) | ✅ 总是 | ~200 ns | 用于状态跟踪 |
| Service LB (socket) | ⚠️ 部分 | ~100 ns | socketLB.hostNamespaceOnly=true |
| Hubble 跟踪 | ❌ 禁用 | 0 ns | 你已禁用 |
| Identity Mark | ❌ 禁用 | 0 ns | 你已禁用 |
| 转发决策 | ✅ 总是 | ~50 ns | 必需 |
总计：
- 无网络策略、无 QoS annotation：~550 ns/packet
- 有网络策略：~850-1050 ns/packet
- 有 QoS annotation：~600 ns/packet
---
🔬 性能影响量化
计算实际吞吐量影响
假设：
- 网络带宽：2.5 Gbps = 2,500,000,000 bits/s
- 平均包大小：1500 bytes = 12,000 bits
- 包速率：2,500,000,000 / 12,000 = 208,333 packets/s
BPF 处理时间：
- 每个包：~550 ns
- 每秒：208,333 * 550 ns = 114 ms/s = 11.4% CPU
结论：在 2.5 Gbps 的流量下，Pod veth BPF 程序约消耗 11-12% 的单核 CPU。
⚖️ 是否可以优化或移除？
❌ 不能移除 Pod veth BPF 程序
这些 BPF 程序是 Cilium 在 generic-veth chaining 模式下的核心组件：
┌──────────────────────────────────────────────────────┐
│ 如果移除 Pod veth BPF 程序，你将失去： │
├──────────────────────────────────────────────────────┤
│ ❌ 网络策略执行（Cilium Network Policy） │
│ ❌ Bandwidth Manager（无法设置 EDT timestamp） │
│ ❌ 连接跟踪（无法支持状态化防火墙） │
│ ❌ 可观测性（无法收集流量数据） │
│ ❌ Service 加速（socket-level LB） │
└──────────────────────────────────────────────────────┘
如果你不需要这些功能，就不应该使用 Cilium！
如果你不需要这些功能，就不应该使用 Cilium！
✅ 可以优化的方向
- 禁用不需要的功能
你已经做了一些优化：
hubble.enabled: false # ✅ 已禁用，节省 ~50-100 ns/packet
enableIdentityMark: false # ✅ 已禁用，节省 ~30 ns/packet
可以进一步优化：
# 如果不需要网络策略
policyEnforcementMode: never # 节省 ~200-500 ns/packet，但失去策略功能
# 如果不需要连接跟踪
# 注意：这会影响很多功能，不推荐
---
📊 Pod veth BPF vs 物理网卡 BPF 的开销对比
| 位置 | 当前状态 | 处理内容 | CPU 开销 | 是否必要 |
|---|---|---|---|---|
| Pod veth (xxx_h) | ✅ 附加 | 策略、CT、EDT、转发 | ~550 ns/pkt | ✅ 必要 |
| bond0 | ✅ 附加 | NodePort、Masq、防火墙 | ~300-500 ns/pkt | ❌ 在 chaining 模式下不必要 |
| genev_sys_6081 | ✅ 附加 | 同 bond0 | ~300-500 ns/pkt | ❌ 不必要且有害 |
| ovn0 | ✅ 附加 | 同 bond0 | ~300-500 ns/pkt | ❌ 不必要且有害 |
