technology

eBPF 模式下 CNI 与 kube-proxy 完整关系详解

·8 分钟阅读·3027 字
网络K8s原理高阶
📋 目录

eBPF 模式下 CNI 与 kube-proxy 完整关系详解

核心概念 eBPF 程序直接挂载内核网络钩子，一套 eBPF 程序同时接管 CNI 网络 + Service 代理能力，可完全移除 kube-proxy。

1. 基础前置知识

  1. 传统模式（iptables/ipvs kube-proxy + 标准CNI）
  • CNI（Calico/Flannel）：只负责Pod IP分配、跨主机Pod互通、NetworkPolicy；
  • kube-proxy：独立DaemonSet，在节点维护内核 iptables/ipvs 规则，实现 Service 四层负载均衡、ClusterIP/NodePort/LoadBalancer 转发；
    两者职责完全隔离，互不干涉，两套独立内核规则。
  1. eBPF 模式核心变革
    eBPF 程序直接挂载 Linux 内核网络钩子（tc、xdp、cgroup sock），一套 eBPF 程序同时接管 CNI 网络 + Service 代理能力，可直接移除 kube-proxy，这是两者关系变化的核心。
    主流实现：Cilium CNI（纯eBPF），Calico 也支持 eBPF 代理模式。

2. 两种部署形态下二者关系

2.1. 形态1：标准eBPF CNI（Cilium），完全弃用 kube-proxy（主流生产方案）

2.1.1. 职责融合，CNI 内置替代 kube-proxy 全部能力

Cilium Agent（CNI组件）加载 eBPF 程序到内核，统一承担两套工作：

（1）原有 CNI 本职工作
  • Pod 创建/销毁时分配 IPv4/IPv6 地址；
  • 维护 Pod 跨主机隧道/路由，打通集群 Pod 通信；
  • 实现 NetworkPolicy 网络访问控制（eBPF L3/L4/L7 策略，性能远超 iptables）；
  • 服务发现、DNS 劫持、流量观测、加密隧道等。
（2）接管原 kube-proxy 的所有 Service 转发逻辑（关键）

eBPF 在内核态实现完整 Service 代理，覆盖所有 Service 类型：

  1. ClusterIP：Pod 访问服务时内核直接负载均衡到后端 Endpoint Pod；
  2. NodePort：节点端口流量转发；
  3. LoadBalancer：对接云厂商LB；
  4. ExternalIPs、LocalTraffic 本地路由策略；
  5. SessionAffinity 会话保持、权重分发、本地优先拓扑路由；

2.1.2. 数据流转关系

  1. Cilium Agent 监听 apiserver：同步 Pod、Service、Endpoint、NetworkPolicy 全量资源；
  2. 资源变更后，Agent 编译、下发 eBPF 字节码到节点内核；
  3. 内核 eBPF 程序统一处理两类流量：
  • Pod ↔ Pod：CNI 互通 + NetworkPolicy 过滤；
  • Pod ↔ Service：四层负载均衡转发（原 kube-proxy 能力）；
  1. 不再部署 kube-proxy DaemonSet，节点无独立代理组件，无 iptables/ipvs 规则膨胀问题。

2.1.3. 二者层级关系

eBPF CNI (Cilium) 是上层管控组件，内核eBPF程序是底层统一网络执行引擎，原 kube-proxy 的功能下沉合并进 CNI 的 eBPF 逻辑，kube-proxy 彻底退场，不存在协作关系。

2.2. 形态2：Calico eBPF 混合模式（保留 kube-proxy，分工共存）

Calico eBPF 提供两种模式：

  1. 标准eBPF代理模式（无kube-proxy）：同Cilium，Calico Agent 内置Service eBPF转发，删除kube-proxy；
  2. 纯NetworkPolicy eBPF模式（共存）：
  • Calico eBPF 只负责 Pod 互通、NetworkPolicy；
  • kube-proxy 依旧独立部署，用 ipvs/iptables 处理 Service；
    此时两者职责分离、并行运行、互不依赖：
  • CNI：管控Pod网络、访问策略；
  • kube-proxy：管控Service四层转发；
    内核两套规则独立生效，无功能融合。

3. eBPF 无 kube-proxy 架构核心优势（二者融合带来的变化）

  1. 消除两套内核规则冲突
    传统：CNI iptables 规则 + kube-proxy ipvs/iptables 两套表，规则数万条，匹配链过长，延迟高；
    eBPF：单套内核程序，匹配路径短，转发性能大幅提升。
  2. Endpoint 更新毫秒级生效
    kube-proxy 全节点同步iptables规则存在延迟；eBPF map 直接在内核更新后端Pod列表，无用户态同步开销。
  3. 本地路由拓扑感知（Topology Hints）原生支持
    eBPF 内核可直接识别同节点/同可用区后端Pod，优先本地转发，减少跨主机流量，传统kube-proxy ipvs实现复杂。
  4. L7 能力统一集成
    CNI eBPF 可同时做四层转发+七层流量控制（限流、TLS、HTTP过滤），kube-proxy 仅四层，无法扩展。
  5. 减少集群组件数量
    无需维护 kube-proxy DaemonSet，降低运维复杂度、减少节点资源占用。

4. 关键区分：传统 vs eBPF 架构对比

维度传统架构 iptables/ipvs + CNIeBPF CNI（Cilium，移除kube-proxy）
Service转发执行者kube-proxy（用户态程序，操作内核ipvs/iptables）CNI Agent下发eBPF，内核直接处理
NetworkPolicy执行者CNI iptablesCNI eBPF
组件关系完全独立、两套内核规则CNI统一管控，融合两套能力，无kube-proxy
规则存储iptables链 / ipvs虚拟服务eBPF Map（内核哈希表）
组件数量CNI DaemonSet + kube-proxy DaemonSet仅一套CNI DaemonSet

5. 常见面试核心总结

  1. 纯eBPF Cilium模式（主流）
    CNI 基于 eBPF 在内核同时实现「Pod网络互通、NetworkPolicy、Service四层负载均衡」，完全废弃 kube-proxy；CNI Agent 统一监听 apiserver 的 Pod/Service/Endpoint 资源，下发一套 eBPF 程序统一处理所有网络流量，kube-proxy 不再存在，二者无协作关系，CNI 替代了 kube-proxy。
  2. Calico 共存模式
    若仅开启eBPF NetworkPolicy，不开启eBPF Service代理，则 CNI 只负责Pod互通与策略，kube-proxy 保留独立运行，二者职责完全拆分，并行工作、互不依赖。
  3. 本质关系变化
    传统架构：CNI、kube-proxy 是两个独立组件，两套内核网络逻辑；
    eBPF 完整代理架构：CNI 升级为统一网络管控平面，通过内核eBPF程序吞并 kube-proxy 的全部Service转发能力，kube-proxy 不再需要部署。

关联文档

返回首页订阅更新