2. Cilium基础回顾：架构总览与eBPF原理

在深入准入控制与故障排查之前，有必要重新梳理Cilium的核心架构与底层技术。Cilium并非简单的CNI插件，而是一个基于eBPF（extended Berkeley Packet Filter）的数据平面与控制平面平台。理解其组件分工、eBPF的运行机制以及与kube-proxy的差异，是后续章节排错与策略配置的基础。

2.1 Cilium架构总览

Cilium采用DaemonSet + Deployment的部署模式，由四个核心组件构成：

组件	部署形态	核心职责
Cilium Agent	DaemonSet（每节点一个）	管理eBPF程序、本地路由、端点（Endpoint）状态、网络策略执行
Cilium Operator	Deployment（通常1~2副本）	处理集群级任务：IPAM分配、Service后端子集同步、CiliumNode资源管理
Cilium CNI	二进制插件（由kubelet调用）	将Pod接入Cilium网络，配置网络命名空间与eBPF映射
Cilium CRD	Kubernetes自定义资源	定义网络策略（CiliumNetworkPolicy）、服务映射（CiliumService）、端点标识等

2.2 eBPF原理简述

eBPF是一项允许用户在Linux内核中安全运行沙箱化程序的技术。Cilium利用eBPF实现网络数据包处理、负载均衡、可观测性与安全策略，无需修改内核代码或加载内核模块。

2.2.1 eBPF程序生命周期

1. 编写与编译： 使用C语言编写eBPF程序，通过LLVM/Clang编译为BPF字节码。
2. 验证： 内核BPF验证器检查字节码的安全性（无死循环、有限指令数、合法内存访问）。
3. 加载与JIT编译： 通过系统调用加载，内核即时编译器（JIT）将字节码转换为本地机器指令。
4. 挂载与事件驱动： 将eBPF程序挂载到内核钩子点（如XDP、TC、Socket、kprobe、tracepoint）。
5. 数据交互： 通过BPF Map与用户空间（Cilium Agent）交换数据。

2.3 Cilium与kube-proxy对比

Cilium可以完全替代kube-proxy，提供更高效的Service负载均衡与网络策略执行。以下是核心差异：

对比维度	kube-proxy	Cilium (eBPF模式)
数据平面技术	iptables / IPVS（内核态规则匹配）	eBPF（内核态程序直接转发）
Service负载均衡	通过DNAT规则修改目标地址	通过BPF Map直接查找后端，无连接跟踪开销
性能特征	规则数量增加时性能线性下降	O(1) 查找，规则数量不影响转发性能
网络策略	不支持（需额外组件如Calico/NetworkPolicy）	原生支持L3/L4/L7策略，直接编译为eBPF
可观测性	依赖外部工具（如conntrack）	内置Hubble，提供流日志、TCP指标、DNS监控
部署复杂度	默认集成，无需额外配置	需安装Cilium并设置kubeProxyReplacement=true

2.3.1 关键优势场景

• 大规模集群： 当Service数量超过1000时，iptables规则膨胀导致CPU飙升，Cilium的eBPF哈希表查找保持稳定。
• 高吞吐节点： eBPF XDP模式在网卡驱动层直接处理数据包，延迟降低30%~50%。
• 安全合规： 基于身份的安全策略（Identity-based Policy）而非IP，避免Pod重建后IP变化导致的策略失效。