1. Cilium架构总览

1.1 项目背景与定位

Cilium 是一个基于 eBPF(extended Berkeley Packet Filter)技术的开源云原生网络、安全与可观测性项目。它最初由 Isovalent(现被 Cisco 收购)于 2016 年发起,旨在解决传统容器网络方案(如 Calico、Flannel)在 Kubernetes 环境下存在的性能瓶颈与安全粒度不足问题。

Cilium 的核心优势在于将 eBPF 程序直接注入 Linux 内核,绕过复杂的 iptables 规则链和用户态代理,实现微秒级延迟和线性扩展的数据路径。它天然支持 Kubernetes 的 NetworkPolicy、Service Mesh(如 Istio 的 Ambient Mesh 模式)、以及基于身份的安全隔离(Identity-based Security),而非传统的 IP 地址 ACL。

关键洞察: Cilium 不是简单的 CNI 插件,而是一个完整的“内核级云原生安全与网络平台”。它通过 eBPF 将控制面策略直接编译为内核字节码,实现了“策略即代码”的零信任安全模型。

1.2 核心组件架构

Cilium 采用数据面与控制面分离的微服务架构。控制面负责策略下发、身份管理和集群状态同步;数据面则在内核中执行 eBPF 程序,处理实际的数据包转发与安全过滤。下表列出了三大核心组件的职责与部署方式:

组件名称部署形态核心职责关键特性
Cilium AgentDaemonSet(每节点一个)管理本地 eBPF 程序、监听 Kubernetes API、维护本地 BPF Map直接与内核交互,执行策略编译与加载
Cilium OperatorDeployment(通常 1~2 副本)集群级协调:IPAM、Service 同步、身份管理(Identity)处理全局状态,不参与数据路径
Cilium CNI Plugin二进制插件(由 kubelet 调用)容器网络接口实现:分配 IP、配置网络命名空间轻量级,仅负责 Pod 网络创建与销毁

1.3 数据面与控制面分离设计

Cilium 的架构设计严格遵循控制面与数据面分离原则,这是其高性能与高安全性的基石。控制面组件(Agent、Operator)运行在用户态,负责策略计算与状态管理;数据面完全运行在内核态 eBPF 虚拟机中,负责实际的数据包处理。

Cilium 控制面与数据面分离架构 控制面(用户态) Kubernetes API Cilium Operator Cilium Agent 控制面职责: • Operator:集群级 IPAM、Identity 分配、Service 同步(不参与数据路径) • Agent:监听 API、编译 eBPF 策略、管理本地 BPF Map、与内核交互 数据面(内核态 eBPF) eBPF 程序 (XDP / TC / LSM 钩子) BPF Map (策略表 / 端点状态 / 指标) Linux 网络栈 (veth / 路由 / netfilter) 数据面职责: • 直接在内核中执行数据包转发、负载均衡、安全策略检查 • 无用户态上下文切换,延迟低至微秒级 • 通过 BPF Map 与控制面 Agent 共享状态(策略更新无需重启数据路径) 策略下发 / Map 更新

1.4 组件交互流程

当一个新的 Pod 在 Kubernetes 集群中被调度时,Cilium 各组件的协作流程如下:

  1. kubelet 调用 CNI Plugin: kubelet 在创建 Pod 网络命名空间时,调用 Cilium CNI 二进制插件。
  2. CNI Plugin 请求 Agent: CNI 插件通过 Unix Socket 向本节点的 Cilium Agent 发送请求,要求分配网络接口和 IP 地址。
  3. Agent 分配端点: Agent 为该 Pod 创建 Endpoint 对象,分配唯一的 Identity(安全身份标识),并写入 BPF Map。
  4. Operator 协调 IPAM: 如果集群启用了 CRD-backed IPAM,Operator 负责从 IP 池中分配 CIDR 并同步到节点。
  5. Agent 加载 eBPF 程序: Agent 根据全局 NetworkPolicy 和本地端点信息,编译并加载 eBPF 程序到网络接口(如 veth pair 的宿主机端)。
  6. 数据面开始工作: 此后,该 Pod 的所有进出流量都由内核中的 eBPF 程序直接处理,无需再经过用户态 Agent。
性能优势: 上述流程中,步骤 5 和 6 是关键。eBPF 程序一旦加载,后续数据包处理路径完全在内核中完成,避免了传统方案中 iptables 规则遍历(O(n) 复杂度)和用户态代理(如 Envoy)的上下文切换开销。Cilium 的数据面延迟通常在 5~20 微秒级别。

1.5 CNI Plugin 的轻量角色

与 Calico 或 Flannel 的 CNI 插件不同,Cilium 的 CNI 插件极其轻量。它不负责网络策略执行或路由表维护,仅完成以下三项基本操作:

  • 创建 veth pair 并将一端移入 Pod 网络命名空间
  • 调用 Agent 的 gRPC 接口获取 IP 地址和 MAC 地址
  • 配置 Pod 内的默认路由

所有复杂的策略逻辑、负载均衡、可观测性数据采集,均由 Agent 通过 eBPF 在内核中完成。这种设计使得 CNI 插件的故障域极小,即使 CNI 插件崩溃,已运行的 Pod 网络也不会中断。

Cilium Pod 创建交互时序 kubelet CNI Plugin Cilium Agent Cilium Operator eBPF 内核 1. 创建 Pod 2. CNI 请求 3. 分配端点 4. IPAM 协调 5. 加载 eBPF 6. 数据面运行

1.6 架构设计总结

Cilium 的架构设计体现了云原生时代的核心原则:

  • 关注点分离: 控制面(Agent/Operator)负责策略编排与状态管理,数据面(eBPF)负责高速转发与安全执行。
  • 最小权限: CNI 插件仅做网络接口创建,不接触策略逻辑;Operator 不直接操作内核。
  • 无代理数据路径: 所有数据包处理在内核中完成,无需 sidecar 代理或用户态转发,延迟和资源开销极低。
  • 热更新能力: 通过 BPF Map 实现策略的动态更新,无需重启数据面或重建连接。
注意: 虽然 Cilium 的数据面性能优异,但其控制面组件(尤其是 Agent)对 Kubernetes API 的依赖较强。在 API Server 过载或 etcd 抖动时,Agent 的策略同步可能延迟,导致新 Pod 的网络策略生效滞后。生产环境中建议为 Cilium Agent 配置独立的 API 优先级和限流参数。