mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
1514 字
5 分钟
eBPF 在 Kubernetes
2026-04-11

Kubernetes 的网络模型是”每个 Pod 有独立 IP、Pod 间可以直接通信”——这个看似简单的模型背后,需要 CNI 插件处理 IP 分配、路由、网络策略、Service 负载均衡等复杂逻辑。传统方案依赖 iptables/kube-proxy,在大规模集群中性能急剧下降。eBPF 提供了一种全新的实现方式——用可编程的数据面替代固定的规则匹配,用 Map 查找替代线性遍历。

本章从 K8s 网络基础设施的角度,详解 eBPF 如何重塑 CNI、kube-proxy、NetworkPolicy 和 Service Mesh。

一、K8s 网络基础设施的演进#

1.1 三代网络方案#

timeline title K8s 网络方案演进 第一代 : iptables kube-proxy : bridge/iptables CNI : 简单但性能差 第二代 : IPVS kube-proxy : Calico/Flannel VXLAN : 性能改善但仍有瓶颈 第三代 : eBPF kube-proxy 替代 : Cilium eBPF CNI : 高性能 + 可编程 + 身份安全

1.2 eBPF 在 K8s 中的角色#

角色传统方案eBPF 方案
CNICalico/Flannel/WeaveCilium eBPF CNI
kube-proxyiptables/IPVSCilium eBPF 替代
NetworkPolicyiptables 规则Cilium 身份策略
Service MeshIstio SidecarCilium Ambient Mesh
可观测性Prometheus + AgentHubble eBPF
安全Seccomp/AppArmorLSM BPF + Tetragon

二、eBPF CNI 对比#

2.1 主流 CNI 对比#

CNI数据面网络模式eBPF 使用性能功能
CiliumeBPFVXLAN/路由/直连全面最高最丰富
Calicoiptables/BPFVXLAN/路由部分丰富
FlanneliptablesVXLAN/host-gw简单
WeaveiptablesVXLAN中等
AWS VPC CNIiptablesVPC 直连AWS 专用
GKE Dataplane V2eBPFGKE 专用GKE 专用

2.2 Cilium vs Calico eBPF#

维度CiliumCalico eBPF
eBPF 覆盖全面(XDP+TC+Socket)部分(TC)
kube-proxy 替代完全替代不替代
身份安全基于标签基于 IP
L7 策略Envoy 集成仅 L3/L4
Hubble 可观测性
ClusterMesh
Ambient Mesh
社区活跃度极高

2.3 选择 CNI 的决策树#

flowchart TD START["选择 CNI"] --> Q1{"需要 eBPF 能力?"} Q1 -->|"否"| Q2{"云厂商?"} Q2 -->|"AWS"| AWS["AWS VPC CNI"] Q2 -->|"GKE"| GKE["GKE Dataplane V2"] Q2 -->|"其他"| FLANNEL["Flannel<br/>简单场景"] Q1 -->|"是"| Q3{"需要全面 eBPF?"} Q3 -->|"是"| CILIUM["Cilium<br/>全面 eBPF CNI"] Q3 -->|"部分"| CALICO["Calico eBPF<br/>部分 eBPF"] style CILIUM fill:#c8e6c9,stroke:#2e7d32 style CALICO fill:#fff9c4,stroke:#f9a825

三、kube-proxy 替代原理#

3.1 iptables kube-proxy 的问题#

传统 kube-proxy 使用 iptables 实现 Service 负载均衡,核心问题是线性匹配——每条规则逐条遍历,规则数与 Service/Endpoint 数量成正比:

sequenceDiagram participant Pod as Client Pod participant IPT as iptables 规则链 participant EP as Backend Pod Pod->>IPT: 发起请求到 ClusterIP Note over IPT: 遍历规则 1...N IPT->>IPT: 匹配 Service 规则 IPT->>IPT: 随机选择 Endpoint IPT->>EP: DNAT 转发
集群规模Service 数iptables 规则数延迟
100 节点1,000~50,000<1ms
1,000 节点5,000~250,0005-10ms
5,000 节点20,000~1,000,00050-100ms

3.2 Cilium eBPF 替代方案#

Cilium 用 eBPF Map 实现常数时间查找——O(1) 替代 O(N):

flowchart LR REQ["请求到达"] --> LOOKUP["eBPF Map 查找<br/>O(1) 常数时间"] LOOKUP --> SELECT["后端选择<br/>一致性哈希"] SELECT --> DNAT["DNAT 转发"] style LOOKUP fill:#c8e6c9,stroke:#2e7d32
Service 类型eBPF 处理路径说明
ClusterIPTC ingress → Map 查找 → DNATPod 内直接转发
NodePortXDP → TC → Map 查找 → DNATXDP 在驱动层处理
LoadBalancerXDP → TC → Map 查找 → DNAT同 NodePort 路径
ExternalIPTC ingress → Map 查找 → SNAT+DNAT需要源地址转换
Note

Cilium 的 kube-proxy 替代有两种模式:strict(完全替代,不运行 kube-proxy)和 partial(部分替代,保留 kube-proxy 处理边缘场景)。生产环境推荐 strict 模式。

四、Cilium 的 K8s 集成#

4.1 Cilium 在 K8s 中的部署#

# Cilium Helm 配置(关键参数)
kubeProxyReplacement: strict # 完全替代 kube-proxy
hubble:
enabled: true # 启用 Hubble
relay:
enabled: true # 启用 Hubble Relay
ui:
enabled: true # 启用 Hubble UI
operator:
replicas: 2 # Operator 副本数
ipam:
mode: kubernetes # IPAM 模式
routingMode: native # 路由模式(直连)
tunnelProtocol: vxlan # 隧道协议
autoDirectNodeRoutes: true # 自动直连路由
bandwidthManager:
enabled: true # 带宽管理
bpf:
lbMode: snat # 负载均衡模式

4.2 Cilium 处理的 K8s 网络功能#

功能eBPF 程序说明
ClusterIP ServiceTC eBPFDNAT 到后端 Pod
NodePort ServiceXDP + TCXDP 加速 + TC DNAT
LoadBalancer ServiceXDP + TCXDP 加速 + TC DNAT
HostPortTC eBPFDNAT 到 Pod
NetworkPolicyTC eBPF身份策略匹配
Pod-to-Pod 路由TC eBPF路由查找 + 转发
Pod-to-ExternalTC egressSNAT 到节点 IP
DNS 策略TC eBPFDNS 查询拦截

五、Ambient Mesh:无边车 Service Mesh#

5.1 传统 Sidecar vs Ambient Mesh#

flowchart TB subgraph Sidecar模式["Sidecar 模式"] APP1["应用 Pod"] -->|"每个 Pod<br/>注入 Envoy"| SC1["Envoy Sidecar<br/>150+ MB 内存"] APP2["应用 Pod"] --> SC2["Envoy Sidecar"] APP3["应用 Pod"] --> SC3["Envoy Sidecar"] end subgraph Ambient模式["Ambient Mesh(eBPF)"] APP4["应用 Pod<br/>无 Sidecar"] --> NODE_BPF["Node 级 eBPF<br/>共享 L4 代理"] APP5["应用 Pod"] --> NODE_BPF APP6["应用 Pod<br/>可选 L7 Envoy"] --> NODE_BPF end style Sidecar模式 fill:#ffcdd2,stroke:#c62828 style Ambient模式 fill:#c8e6c9,stroke:#2e7d32

5.2 Ambient Mesh 的架构#

实现功能
L4(节点级)eBPF + Envoy 节点代理mTLS、L4 路由、可观测性
L7(可选)共享 Envoy 代理HTTP/gRPC 策略、限流、重试

5.3 Ambient Mesh 的优势#

优势说明
无 Sidecar不注入 Envoy 到 Pod,零侵入
内存节省节点级共享代理,每个 Pod 不额外占用内存
延迟降低eBPF L4 处理比 Sidecar 模式延迟更低
渐进式启用可以逐 Namespace 启用,无需修改 Pod
L4/L7 分离L4 自动启用,L7 按需启用

5.4 Ambient Mesh 部署#

# 启用 Cilium Ambient Mesh
helm install cilium cilium/cilium \
--set kubeProxyReplacement=strict \
--set hubble.enabled=true \
--set ambient.enabled=true \
--namespace kube-system
# 将 Namespace 加入 Ambient Mesh
kubectl annotate namespace default \
istio.io/dataplane-mode=ambient
# 验证
cilium status
kubectl get pods -n kube-system -l app=cilium
Note

Ambient Mesh 是 Istio + Cilium 的联合项目。Istio 提供 L7 策略引擎,Cilium 提供 eBPF L4 数据面。两者协同实现了无边车的 Service Mesh。

六、NetworkPolicy 增强#

6.1 标准 K8s NetworkPolicy vs CiliumNetworkPolicy#

能力标准 NetworkPolicyCiliumNetworkPolicy
L3/L4 规则
L7 规则(HTTP/gRPC)
DNS 策略
身份选择(基于 IP)(基于标签)
跨集群策略
ICMP 规则
端口范围
否定规则

6.2 CiliumNetworkPolicy 示例#

# L7 HTTP 策略
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: l7-http-rule
spec:
endpointSelector:
matchLabels:
app: backend
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "80"
protocol: TCP
rules:
http:
- method: GET
path: "/api/v1/.*"
- method: POST
path: "/api/v1/data"
# DNS 策略:只允许访问特定域名
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: dns-rule
spec:
endpointSelector:
matchLabels:
app: frontend
egress:
- toEndpoints:
- matchLabels:
k8s:io.kubernetes.pod.namespace: kube-system
k8s-app: kube-dns
toPorts:
- ports:
- port: "53"
protocol: UDP
rules:
dns:
- matchPattern: "myapp.example.com"
- matchPattern: "*.google.com"

七、多集群网络#

7.1 ClusterMesh 配置#

# 集群 A 配置
cilium clustermesh enable --service-id 1
# 集群 B 配置
cilium clustermesh enable --service-id 2
# 连接集群
cilium clustermesh connect --destination-context cluster-b
# 验证
cilium clustermesh status

7.2 全局 Service#

# 全局 Service(跨集群负载均衡)
apiVersion: v1
kind: Service
metadata:
name: my-global-service
annotations:
service.cilium.io/global: "true"
spec:
type: ClusterIP
ports:
- port: 80
targetPort: 8080
selector:
app: backend

八、Cilium eBPF 数据管线#

8.1 完整数据路径#

Cilium 的 eBPF 数据管线覆盖了从网卡到 Socket 的完整路径:

flowchart LR NIC["网卡收包"] --> XDP["XDP 程序<br/>L4 负载均衡<br/>DDoS 防护"] XDP --> TC_IN["TC ingress<br/>NetworkPolicy<br/>Service DNAT"] TC_IN --> L2["L2 转发<br/>Pod 路由"] L2 --> SOCK["Socket 层<br/>短电路优化"] SOCK --> TC_OUT["TC egress<br/>SNAT<br/>带宽管理"] TC_OUT --> NIC_OUT["网卡发包"] style XDP fill:#c8e6c9,stroke:#2e7d32 style TC_IN fill:#bbdefb,stroke:#1565c0 style TC_OUT fill:#fff9c4,stroke:#f9a825

8.2 iptables vs IPVS vs eBPF 性能对比#

维度iptables kube-proxyIPVS kube-proxyCilium eBPF
Service 查找O(N) 线性遍历O(1) 哈希查找O(1) eBPF Map 查找
规则更新全量替换增量更新原子更新
内存占用规则数 × 条目大小哈希表eBPF Map
1000 Service 延迟~5ms~0.1ms~0.05ms
20000 Service 延迟~100ms~0.1ms~0.05ms
CPU 开销高(规则遍历)极低

九、ClusterMesh 深入#

9.1 ClusterMesh 架构#

flowchart TB subgraph 集群A["集群 A (service-id=1)"] CA_POD1["Pod A1"] --> CA_AGENT["Cilium Agent"] CA_AGENT --> CA_KV["etcd"] end subgraph 集群B["集群 B (service-id=2)"] CB_POD1["Pod B1"] --> CB_AGENT["Cilium Agent"] CB_AGENT --> CB_KV["etcd"] end CA_AGENT <-->|"跨集群身份同步<br/>etcd gateway"| CB_AGENT style 集群A fill:#e3f2fd,stroke:#1565c0 style 集群B fill:#e8f5e9,stroke:#2e7d32

9.2 ClusterMesh 限制与调试#

限制说明
最大集群数255(受 service-id 限制)
跨集群延迟取决于集群间网络,通常 1-10ms
身份冲突不同集群的标签可能映射到相同身份 ID
调试命令cilium clustermesh statuscilium clustermesh connect
Warning

ClusterMesh 的跨集群流量经过隧道封装,会增加约 50-100 字节的包头开销。对于延迟敏感型应用,建议将服务部署在同一集群内,仅将管理流量跨集群。

十、eBPF K8s 安全:Tetragon#

10.1 Tetragon 在 K8s 中的部署#

# Tetragon DaemonSet 关键配置
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: tetragon
namespace: kube-system
spec:
selector:
matchLabels:
app: tetragon
template:
spec:
serviceAccountName: tetragon
containers:
- name: tetragon
image: cilium/tetragon:latest
securityContext:
capabilities:
add: ["CAP_BPF", "CAP_PERFMON"]

10.2 Pod 安全监控#

Tetragon 可以监控 Pod 内的进程行为,检测容器逃逸、特权提升等安全事件:

# 监控特定 Namespace 的进程执行
kubectl exec -n kube-system ds/tetragon -- \
tetra getevents --namespace-allowlist default
# 检测容器内的 bpf() 系统调用(可能的容器逃逸)
kubectl exec -n kube-system ds/tetragon -- \
tetra getevents --process-cred-change

十一、动手实践#

11.1 部署 Cilium 替代 kube-proxy#

# 移除 kube-proxy
kubectl -n kube-system delete ds kube-proxy
# 部署 Cilium
helm install cilium cilium/cilium \
--set kubeProxyReplacement=strict \
--set hubble.enabled=true \
--namespace kube-system
# 验证
cilium status
kubectl get svc -A # Service 应正常工作

11.2 启用 Hubble 可观测性#

# 启用 Hubble
cilium hubble port-forward&
# 查看流量
hubble observe --since 5m
# 查看 DNS 查询
hubble observe --type l7 --protocol dns
# 查看 DROP 事件
hubble observe --type drop

11.3 创建 CiliumNetworkPolicy#

# 创建 L7 策略
kubectl apply -f cilium-policy.yaml
# 验证策略生效
cilium policy get
# 测试策略
kubectl exec frontend-pod -- curl backend:80/api/v1/users # 应允许
kubectl exec frontend-pod -- curl backend:80/admin # 应拒绝

十二、本章小结#

上一章深入探讨了eBPF 与 WebAssembly 的融合。 本章详解了 eBPF 在 Kubernetes 中的应用:

主题核心要点关键词
CNI 对比Cilium 全面 eBPF,Calico 部分 eBPF,Flannel 无 eBPFCNI 对比
kube-proxy 替代Cilium eBPF Map 查找替代 iptables 线性匹配kube-proxy 替代
Ambient Mesh无边车 Service Mesh,eBPF L4 + Envoy L7Ambient Mesh
NetworkPolicy 增强CiliumNetworkPolicy 支持 L7/DNS/身份/跨集群NetworkPolicy 增强
多集群网络ClusterMesh 全局身份和跨集群 Service多集群网络

支持与分享

如果这篇文章对你有帮助,欢迎支持作者或分享给更多人

eBPF 在 Kubernetes
https://blog.souloss.com/posts/ebpf/ebpf-in-k8s/
作者
Souloss
发布于
2026-04-11
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

相关文章 智能推荐
1
eBPF 网络全景
eBPF eBPF 正在重新定义 Linux 网络栈——从连接跟踪、NAT 到 kube-proxy 替代,从 Socket Filter 到 Sk_msg 重定向,eBPF 提供了比 iptables/netfilter 更高性能、更灵活的网络方案。本章从宏观视角展示 eBPF 网络的全景,详解连接跟踪、NAT、kube-proxy 替代、Socket 层 eBPF,并对比 eBPF 与传统网络方案的架构差异。
2
eBPF 与 WebAssembly
eBPF eBPF 提供内核可编程能力,WebAssembly 提供跨平台可移植性——两者的融合会带来什么?本章详解 Wasm-eBPF 项目、用户态 eBPF 运行时、eBPF 程序的 Wasm 封装,以及 eBPF + Wasm 在边缘计算、插件系统、跨平台可观测性中的应用前景。
3
eBPF 可观测性
eBPF eBPF 最大的应用场景是可观测性——零侵入、低开销、内核级的全链路追踪。本章详解三大可观测性工具链——bpftrace(一行命令追踪内核)、BCC(Python 前端 + 丰富工具集)、Beyla(零侵入应用性能监控),并通过实战展示性能分析、分布式追踪、应用性能监控的完整工作流。
4
eBPF 生产部署
eBPF eBPF 生产部署实践——性能开销分析、调试技巧、版本兼容、内核版本要求与升级策略。
5
eBPF 与内存管理
eBPF eBPF 程序的内存使用是生产部署中的关键考量——Map 占用多少内存?eBPF 程序的栈空间有多大?容器环境中的 eBPF 内存如何计费?本章详解 eBPF 的内存模型、Map 内存开销计算、容器内存追踪、eBPF-mm 子系统,以及内存限制下的优化策略。