Cilium 基础架构：数据平面、eBPF 核心机制与 Kubernetes 集成原理

Cilium 并非传统意义上的 Sidecar 代理，而是一个基于 eBPF（extended Berkeley Packet Filter）技术构建的云原生网络、安全与可观测性平台。理解 Cilium 的基础架构，是掌握其在服务网格升级中与 Envoy 协同工作的前提。本节将深入剖析 Cilium 的数据平面、eBPF 核心机制以及它与 Kubernetes 的深度集成原理。

2.1 Cilium 数据平面架构

Cilium 的数据平面完全运行在 Linux 内核中，通过 eBPF 程序直接接管网络路径。它摒弃了传统的 iptables 或 IPVS 模式，实现了高性能、低延迟的数据包处理。

核心设计理念： Cilium 将网络策略、负载均衡、安全隔离和可观测性逻辑下沉到内核 eBPF 钩子中，避免了数据包在用户态和内核态之间的频繁拷贝与上下文切换。

下图展示了 Cilium 数据平面的核心组件及其在 Kubernetes 节点上的交互关系：

Cilium 数据平面架构（单节点视图） Kubernetes 节点 用户空间 (User Space) • Cilium Agent (DaemonSet) • Cilium Operator • Hubble Relay / UI • Envoy Proxy (可选) 内核空间 (Kernel Space) • eBPF 程序 (网络/跟踪/安全) • BPF Map (共享数据结构) • Cilium CNI 插件 • 网络栈 (TC/XDP 钩子) • 策略执行点 Pod 网络与端点 Pod A eth0: 10.0.1.2 Labels: app=frontend Identity: 1001 Pod B eth0: 10.0.2.3 Labels: app=backend Identity: 1002 Cilium Endpoint 管理 • 每个 Pod 对应一个 Endpoint • 维护 Identity 与策略映射 • 通过 BPF Map 同步到内核 eBPF 服务负载均衡 • 基于 BPF Map 的 Service 转发 • 支持 DSR、Maglev 一致性哈希 gRPC BPF Map 说明：Cilium Agent 通过 gRPC 与 kube-apiserver 交互，并将策略和端点信息写入 BPF Map，eBPF 程序在内核中直接读取 Map 执行转发与策略。

2.2 eBPF 核心机制

eBPF 是 Cilium 的基石。它是一种在内核沙箱中运行用户定义程序的技术，允许在不修改内核源码或加载内核模块的情况下，安全地扩展内核功能。

2.2.1 eBPF 程序生命周期

  1. 编写与编译： 开发者使用 C 语言编写 eBPF 程序，通过 LLVM/Clang 编译为 BPF 字节码。
  2. 验证与加载： Cilium Agent 通过 bpf() 系统调用将字节码加载到内核。内核验证器（Verifier）会检查程序的安全性（无死循环、有限内存访问等）。
  3. JIT 编译与附加： 验证通过后，内核即时编译器（JIT）将字节码转换为本地机器指令，并附加到指定的内核钩子（如网络数据包入口、系统调用出口、跟踪点等）。
  4. 事件驱动执行： 当内核事件（如接收网络包）触发钩子时，eBPF 程序自动执行，处理数据并更新 BPF Map。

2.2.2 关键 eBPF 钩子与 Map

组件/概念 说明 Cilium 中的应用
XDP (eXpress Data Path) 在网络驱动层（最早期）处理数据包，性能极高。 DDoS 防护、负载均衡的早期转发决策。
TC (Traffic Control) 在内核网络协议栈的 ingress/egress 钩子处理数据包。 网络策略执行、封装/解封装（VXLAN/Geneve）、带宽管理。
cgroup 钩子 在 cgroup 级别拦截系统调用或网络操作。 Socket 级别的负载均衡、进程级安全策略。
Tracepoint/Kprobe 动态或静态跟踪内核函数调用。 Hubble 可观测性：捕获 TCP 连接、DNS 请求、HTTP 事件。
BPF Map 用户空间与内核空间、不同 eBPF 程序之间共享数据的关键结构。 存储策略规则、端点信息、连接跟踪表、负载均衡后端列表。
性能优势： 传统 iptables 规则链在处理复杂策略时，数据包需要遍历大量线性规则。Cilium 的 eBPF 程序使用哈希表（BPF Map）进行 O(1) 复杂度的查找，延迟和 CPU 开销显著降低。

2.3 Cilium 与 Kubernetes 集成原理

Cilium 作为 CNI（Container Network Interface）插件，深度集成到 Kubernetes 生态中。它利用 Kubernetes 的 API 作为单一数据源，自动发现 Pod、Service、NetworkPolicy 等资源，并将其转化为 eBPF 程序与 Map。

2.3.1 集成工作流

  1. Pod 创建事件： kubelet 调用 Cilium CNI 二进制文件为 Pod 配置网络命名空间。
  2. 端点分配： Cilium Agent 为 Pod 分配 IP 地址，并创建一个 CiliumEndpoint 对象，记录 Pod 的标签、安全身份（Security Identity）等信息。
  3. 策略计算： Agent 监听 Kubernetes NetworkPolicy 和 CiliumNetworkPolicy (CRD)，计算适用于该端点的策略规则。
  4. BPF Map 更新： Agent 将端点信息和策略规则写入内核的 BPF Map。
  5. 数据路径生效： 附加在 Pod 对端 veth 设备上的 eBPF 程序，在数据包进出时直接查询 BPF Map，执行转发、封装、策略检查等操作。

2.3.2 身份与策略模型

Cilium 引入了基于身份（Identity）的安全模型，而非传统的基于 IP 或 CIDR 的模型。

  • Security Identity： 每个 Pod 根据其标签组合被分配一个 24 位的数字身份。例如，app=frontend,env=prod 可能对应 Identity 1001。
  • 策略简化： 网络策略不再需要关心 Pod IP 的变化。策略规则直接引用 Identity，例如“允许 Identity 1001 访问 Identity 1002 的 80 端口”。
  • 大规模优势： 在拥有数万个 Pod 的集群中，基于 Identity 的策略规则数量远少于基于 IP 的规则，极大地降低了 BPF Map 的大小和策略计算复杂度。
注意： 虽然 Cilium 可以完全替代 kube-proxy，但在服务网格场景下，Cilium 通常与 Envoy 协同工作。Cilium 负责东西向流量（Pod 到 Pod）的快速转发和 L3/L4 策略，而 Envoy 负责 L7 流量管理（路由、重试、熔断）和链路追踪。这种分工充分发挥了各自在数据平面和控制平面的优势。

2.3.3 集成架构图

下图展示了 Cilium 如何与 Kubernetes 控制平面交互，并将资源状态同步到数据平面：

Cilium 与 Kubernetes 集成原理 Kubernetes 控制平面 • kube-apiserver • etcd • kube-controller-manager • kube-scheduler Watch Cilium 控制平面 • Cilium Agent • Cilium Operator • Hubble Server • CRD 控制器 bpf() syscall 内核数据平面 • eBPF 程序 • BPF Map • XDP/TC 钩子 Kubernetes 资源与 Cilium CRD Pod / Service NetworkPolicy CiliumNetworkPolicy CiliumEndpoint / Identity

2.4 关键总结

维度 关键点
数据平面 完全基于 eBPF，运行在内核空间，通过 XDP/TC 钩子处理数据包，性能远优于 iptables。
eBPF 核心 安全、可编程的内核扩展机制。程序经过验证、JIT 编译后附加到钩子，通过 BPF Map 与用户空间交互。
Kubernetes 集成 作为 CNI 插件，监听 kube-apiserver 事件，自动管理端点、身份和策略，并将状态同步到 BPF Map。
身份模型 基于标签的 Security Identity 替代 IP 地址，简化策略管理，提升大规模集群下的性能与可扩展性。
← 上一章 📖 返回目录 下一章 →