Kubernetes 的网络模型是”每个 Pod 有独立 IP、Pod 间可以直接通信”——这个看似简单的模型背后,需要 CNI 插件处理 IP 分配、路由、网络策略、Service 负载均衡等复杂逻辑。传统方案依赖 iptables/kube-proxy,在大规模集群中性能急剧下降。eBPF 提供了一种全新的实现方式——用可编程的数据面替代固定的规则匹配,用 Map 查找替代线性遍历。
本章从 K8s 网络基础设施的角度,详解 eBPF 如何重塑 CNI、kube-proxy、NetworkPolicy 和 Service Mesh。
一、K8s 网络基础设施的演进
1.1 三代网络方案
1.2 eBPF 在 K8s 中的角色
| 角色 | 传统方案 | eBPF 方案 |
|---|---|---|
| CNI | Calico/Flannel/Weave | Cilium eBPF CNI |
| kube-proxy | iptables/IPVS | Cilium eBPF 替代 |
| NetworkPolicy | iptables 规则 | Cilium 身份策略 |
| Service Mesh | Istio Sidecar | Cilium Ambient Mesh |
| 可观测性 | Prometheus + Agent | Hubble eBPF |
| 安全 | Seccomp/AppArmor | LSM BPF + Tetragon |
二、eBPF CNI 对比
2.1 主流 CNI 对比
| CNI | 数据面 | 网络模式 | eBPF 使用 | 性能 | 功能 |
|---|---|---|---|---|---|
| Cilium | eBPF | VXLAN/路由/直连 | 全面 | 最高 | 最丰富 |
| Calico | iptables/BPF | VXLAN/路由 | 部分 | 高 | 丰富 |
| Flannel | iptables | VXLAN/host-gw | 中 | 简单 | |
| Weave | iptables | VXLAN | 中 | 中等 | |
| AWS VPC CNI | iptables | VPC 直连 | 中 | AWS 专用 | |
| GKE Dataplane V2 | eBPF | GKE 专用 | 高 | GKE 专用 |
2.2 Cilium vs Calico eBPF
| 维度 | Cilium | Calico eBPF |
|---|---|---|
| eBPF 覆盖 | 全面(XDP+TC+Socket) | 部分(TC) |
| kube-proxy 替代 | 完全替代 | 不替代 |
| 身份安全 | 基于标签 | 基于 IP |
| L7 策略 | Envoy 集成 | 仅 L3/L4 |
| Hubble 可观测性 | ||
| ClusterMesh | ||
| Ambient Mesh | ||
| 社区活跃度 | 极高 | 高 |
2.3 选择 CNI 的决策树
三、kube-proxy 替代原理
3.1 iptables kube-proxy 的问题
传统 kube-proxy 使用 iptables 实现 Service 负载均衡,核心问题是线性匹配——每条规则逐条遍历,规则数与 Service/Endpoint 数量成正比:
| 集群规模 | Service 数 | iptables 规则数 | 延迟 |
|---|---|---|---|
| 100 节点 | 1,000 | ~50,000 | <1ms |
| 1,000 节点 | 5,000 | ~250,000 | 5-10ms |
| 5,000 节点 | 20,000 | ~1,000,000 | 50-100ms |
3.2 Cilium eBPF 替代方案
Cilium 用 eBPF Map 实现常数时间查找——O(1) 替代 O(N):
| Service 类型 | eBPF 处理路径 | 说明 |
|---|---|---|
| ClusterIP | TC ingress → Map 查找 → DNAT | Pod 内直接转发 |
| NodePort | XDP → TC → Map 查找 → DNAT | XDP 在驱动层处理 |
| LoadBalancer | XDP → TC → Map 查找 → DNAT | 同 NodePort 路径 |
| ExternalIP | TC ingress → Map 查找 → SNAT+DNAT | 需要源地址转换 |
Cilium 的 kube-proxy 替代有两种模式:strict(完全替代,不运行 kube-proxy)和 partial(部分替代,保留 kube-proxy 处理边缘场景)。生产环境推荐 strict 模式。
四、Cilium 的 K8s 集成
4.1 Cilium 在 K8s 中的部署
# Cilium Helm 配置(关键参数)kubeProxyReplacement: strict # 完全替代 kube-proxyhubble: enabled: true # 启用 Hubble relay: enabled: true # 启用 Hubble Relay ui: enabled: true # 启用 Hubble UIoperator: 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 Service | TC eBPF | DNAT 到后端 Pod |
| NodePort Service | XDP + TC | XDP 加速 + TC DNAT |
| LoadBalancer Service | XDP + TC | XDP 加速 + TC DNAT |
| HostPort | TC eBPF | DNAT 到 Pod |
| NetworkPolicy | TC eBPF | 身份策略匹配 |
| Pod-to-Pod 路由 | TC eBPF | 路由查找 + 转发 |
| Pod-to-External | TC egress | SNAT 到节点 IP |
| DNS 策略 | TC eBPF | DNS 查询拦截 |
五、Ambient Mesh:无边车 Service Mesh
5.1 传统 Sidecar vs Ambient Mesh
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 Meshhelm install cilium cilium/cilium \ --set kubeProxyReplacement=strict \ --set hubble.enabled=true \ --set ambient.enabled=true \ --namespace kube-system
# 将 Namespace 加入 Ambient Meshkubectl annotate namespace default \ istio.io/dataplane-mode=ambient
# 验证cilium statuskubectl get pods -n kube-system -l app=ciliumAmbient Mesh 是 Istio + Cilium 的联合项目。Istio 提供 L7 策略引擎,Cilium 提供 eBPF L4 数据面。两者协同实现了无边车的 Service Mesh。
六、NetworkPolicy 增强
6.1 标准 K8s NetworkPolicy vs CiliumNetworkPolicy
| 能力 | 标准 NetworkPolicy | CiliumNetworkPolicy |
|---|---|---|
| L3/L4 规则 | ||
| L7 规则 | (HTTP/gRPC) | |
| DNS 策略 | ||
| 身份选择 | (基于 IP) | (基于标签) |
| 跨集群策略 | ||
| ICMP 规则 | ||
| 端口范围 | ||
| 否定规则 |
6.2 CiliumNetworkPolicy 示例
# L7 HTTP 策略apiVersion: cilium.io/v2kind: CiliumNetworkPolicymetadata: name: l7-http-rulespec: 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/v2kind: CiliumNetworkPolicymetadata: name: dns-rulespec: 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 status7.2 全局 Service
# 全局 Service(跨集群负载均衡)apiVersion: v1kind: Servicemetadata: 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 的完整路径:
8.2 iptables vs IPVS vs eBPF 性能对比
| 维度 | iptables kube-proxy | IPVS kube-proxy | Cilium 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 架构
9.2 ClusterMesh 限制与调试
| 限制 | 说明 |
|---|---|
| 最大集群数 | 255(受 service-id 限制) |
| 跨集群延迟 | 取决于集群间网络,通常 1-10ms |
| 身份冲突 | 不同集群的标签可能映射到相同身份 ID |
| 调试命令 | cilium clustermesh status、cilium clustermesh connect |
ClusterMesh 的跨集群流量经过隧道封装,会增加约 50-100 字节的包头开销。对于延迟敏感型应用,建议将服务部署在同一集群内,仅将管理流量跨集群。
十、eBPF K8s 安全:Tetragon
10.1 Tetragon 在 K8s 中的部署
# Tetragon DaemonSet 关键配置apiVersion: apps/v1kind: DaemonSetmetadata: name: tetragon namespace: kube-systemspec: 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-proxykubectl -n kube-system delete ds kube-proxy
# 部署 Ciliumhelm install cilium cilium/cilium \ --set kubeProxyReplacement=strict \ --set hubble.enabled=true \ --namespace kube-system
# 验证cilium statuskubectl get svc -A # Service 应正常工作11.2 启用 Hubble 可观测性
# 启用 Hubblecilium hubble port-forward&
# 查看流量hubble observe --since 5m
# 查看 DNS 查询hubble observe --type l7 --protocol dns
# 查看 DROP 事件hubble observe --type drop11.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 无 eBPF | CNI 对比 |
| kube-proxy 替代 | Cilium eBPF Map 查找替代 iptables 线性匹配 | kube-proxy 替代 |
| Ambient Mesh | 无边车 Service Mesh,eBPF L4 + Envoy L7 | Ambient Mesh |
| NetworkPolicy 增强 | CiliumNetworkPolicy 支持 L7/DNS/身份/跨集群 | NetworkPolicy 增强 |
| 多集群网络 | ClusterMesh 全局身份和跨集群 Service | 多集群网络 |
支持与分享
如果这篇文章对你有帮助,欢迎支持作者或分享给更多人
部分信息可能已经过时






