第277篇：Cilium eBPF 数据面与网络性能

关键词：Cilium、eBPF、XDP、内核旁路、网络性能、数据面、可观测性、零拷贝

一、引言

eBPF（extended Berkeley Packet Filter）是Linux内核的一项革命性技术，它允许在内核中安全地运行沙箱程序。Cilium创新性地将eBPF应用于容器网络，用eBPF程序替代了传统的iptables/netfilter数据面，带来了显著的性能提升和功能增强。

本文将深入解析eBPF在容器网络中的应用原理，分析其性能优势，并探讨eBPF数据面与传统iptables数据面的本质差异。

二、核心概念

2.1 eBPF 技术概述

eBPF的核心能力：

2.2 XDP（eXpress Data Path）

XDP是eBPF在网络数据包处理中的最早Hook点：

XDP的动作：

2.3 Cilium 的 eBPF 数据面架构

Cilium使用eBPF程序替代传统数据面组件：

2.4 eBPF 程序类型

三、技术细节

3.1 eBPF vs iptables 性能对比

iptables的数据包处理路径：

eBPF的数据包处理路径：

性能对比数据：

3.2 eBPF Map 在 Cilium 中的应用

eBPF Map是eBPF程序与用户空间共享数据的关键机制：

3.3 Cilium kube-proxy 替代

Cilium可以完全替代kube-proxy，通过eBPF程序实现Service负载均衡：

传统kube-proxy（iptables模式）： - 每次Service/Endpoints变化，全量重新生成iptables规则 - 规则链遍历，性能随规则数线性下降 - 不支持L7负载均衡

Cilium kube-proxy replacement： - Service/Endpoints变化时，只更新受影响的eBPF Map条目 - 哈希查找，性能与规则数无关 - 支持L7感知负载均衡（基于HTTP头/路径）

3.4 eBPF 安全机制

eBPF程序在内核中运行，其安全性由以下机制保障：

eBPF Verifier检查内容：

3.5 eBPF Map 高级应用

3.6 内核版本与eBPF兼容性

内核升级对Cilium的影响评估：

四、实战配置/案例分析

4.1 Cilium eBPF 数据面配置

# Helm values 启用eBPF模式
# helm install cilium cilium/cilium --namespace kube-system \
#   --set bpf.masquerade=true \
#   --set tunnel=disabled \
#   --set routingMode=native \
#   --set kubeProxyReplacement=strict \
#   --set bpf.hostRouting=true \
#   --set xdp=true

apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: allow-egress-dns
spec:
  endpointSelector: {}  # 匹配所有端点
  egress:
  - toEndpoints:
    - matchLabels:
        k8s:io.kubernetes.pod.namespace: kube-system
        k8s:k8s-app: kube-dns
    toPorts:
    - ports:
      - port: "53"
        protocol: ANY

4.2 查看 eBPF 程序统计

# 1. 查看eBPF程序状态
cilium status

# 2. 查看eBPF程序统计
cilium bpf lb list
cilium bpf nat list
cilium bpf ct list global

# 3. 查看XDP统计
cilium bpf xdp list

# 4. 使用bpftool查看eBPF程序
bpftool prog list
bpftool map list

4.3 Hubble 可观测性

# 1. 部署Hubble
helm install hubble cilium/cilium --namespace kube-system \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

# 2. 查看流量流日志
hubble observe --namespace default

# 3. 查看服务拓扑
hubble profile list
hubble flow get --verdict forwarded

# 4. 生成服务依赖图
hubble lens graph

4.4 故障案例：eBPF程序加载失败

现象：升级内核版本后，Cilium的eBPF程序加载失败，Pod网络中断。

排查过程：

# 1. 检查Cilium状态
cilium status
# 错误: eBPF programs failed to load

# 2. 检查eBPF日志
cilium bpf log dump
# 错误: eBPF verifier rejected the program
# 具体: R1 min value is outside of the allowed range

# 3. 检查内核版本
uname -r
# 内核版本从5.15升级到了6.1

# 4. 检查eBPF兼容性
# 新内核的eBPF验证器更严格, Cilium的eBPF程序需要适配

根因：内核升级后，eBPF验证器（Verifier）的规则发生变化。Cilium旧版本的eBPF程序使用了在新内核中被禁止的某些eBPF指令，导致加载失败。

解决： 1. 升级Cilium到支持新内核的版本 2. 临时降级内核或启用兼容模式 3. 在内核升级前，先在测试环境验证Cilium与新内核的兼容性

五、总结

思考

1. eBPF程序在内核中运行，如果eBPF程序存在bug，是否会影响内核稳定性？eBPF如何保证安全？
2. XDP可以在网卡驱动层就丢弃报文，这对DDoS防护有什么意义？
3. Cilium替代kube-proxy后，原有的iptables规则是否还会生效？两者能否共存？
4. eBPF Verifier在加载eBPF程序时执行哪些检查？如果验证失败，应该如何排查？
5. 不同内核版本对eBPF的支持差异有多大？生产环境应该选择什么内核版本？

下篇预告：第278篇：K8s Ingress 与 Service Mesh 网络