Cilium 与 eBPF 基础：架构、原理与 Kubernetes 角色
在深入 Pod 级容量规划校准之前，必须建立对 Cilium 与 eBPF 的扎实理解。Cilium 并非传统 CNI 插件的简单替代，而是基于 eBPF 技术构建的、面向云原生网络、安全与可观测性的数据平面与控制平面。本章将拆解其核心架构、eBPF 的运行机制，以及 Cilium 在 Kubernetes 集群中的关键角色。
2.1 Cilium 架构概览
Cilium 采用控制面与数据面分离的经典设计，但数据面完全由 eBPF 程序接管，而非传统的 iptables 或 ipvs。其核心组件包括：
| 组件 | 部署位置 | 核心职责 |
|---|---|---|
| Cilium Agent | 每个 Kubernetes 节点（DaemonSet） | 与 kube-apiserver 交互，监听 Pod/Service/NetworkPolicy 事件；编译并加载 eBPF 程序到内核；管理本地端点与标识。 |
| Cilium Operator | 集群级单副本或高可用部署 | 处理集群范围任务：IPAM（IP 地址管理）、CiliumNetworkPolicy 状态聚合、多集群 Service 协调。 |
| Cilium CNI 插件 | 每个节点（二进制文件） | 被 kubelet 调用，负责 Pod 网络接口创建与 IP 分配，并将 Pod 元数据传递给 Cilium Agent。 |
| eBPF 程序 | 内核中（由 Agent 加载） | 数据面核心：处理网络包转发、负载均衡、安全策略执行、可观测性数据采集。 |
| Hubble | Agent 内置 + 独立 Relay | 基于 eBPF 的可观测性层，提供流日志、指标、服务依赖图。 |
架构要点： Cilium Agent 是唯一与内核 eBPF 子系统交互的组件。它通过
cilium-agent --config 启动，使用 bpf() 系统调用将编译后的 ELF 对象加载到内核的特定 hook 点。Operator 不直接操作 eBPF，只处理有状态的控制逻辑。
2.2 eBPF 核心原理
eBPF（extended Berkeley Packet Filter）是一种在内核虚拟机中安全运行沙箱化程序的技术。它允许用户在不修改内核源码或加载内核模块的情况下，动态注入自定义逻辑。其核心工作流包含三个阶段：
- 编写与编译： 使用 C 语言（或 Rust）编写 eBPF 程序，通过 LLVM/Clang 后端编译为 eBPF 字节码（ELF 对象）。
- 验证与加载： 用户态程序（如 Cilium Agent）通过
bpf()系统调用将字节码传入内核。内核验证器（verifier）执行静态分析：检查循环边界、指针安全、栈大小（最大 512 字节），确保程序不会导致内核崩溃或死锁。 - JIT 编译与挂载： 通过验证后，内核即时编译器（JIT）将字节码转换为本地机器指令，并挂载到指定的 hook 点（如 XDP、TC、kprobe、tracepoint、cgroup）。
关键区别： 传统 iptables 规则是线性匹配，复杂度 O(N)；eBPF 程序是编译后的指令流，复杂度 O(1)，且支持哈希表（map）作为有状态存储。这使得 Cilium 在大型集群中具备显著的性能优势。
eBPF 程序通过 Map 与用户态通信。Map 是内核中的键值存储，支持多种类型（哈希、数组、LRU、per-CPU 等）。Cilium 使用 Map 存储端点信息、策略规则、连接跟踪状态。用户态 Agent 通过 bpf() 系统调用的 BPF_MAP_LOOKUP_ELEM / BPF_MAP_UPDATE_ELEM 命令读写这些 Map。
2.3 Cilium 在 Kubernetes 中的角色
Cilium 在 Kubernetes 集群中承担三个核心角色，这些角色直接服务于 Pod 级容量规划的数据采集与策略执行：
| 角色 | 实现机制 | 对容量规划的价值 |
|---|---|---|
| CNI 网络插件 | 通过 eBPF 实现 Pod 网络连通性，支持 Overlay（VXLAN/Geneve）或原生路由（Direct Routing）。 | 提供 Pod IP 分配与网络路径，是采集 Pod 网络流量的基础。 |
| 网络策略引擎 | 使用 eBPF 在 L3/L4/L7 层执行 CiliumNetworkPolicy，无需 iptables。 | 策略规则可标记流量类型，辅助区分业务流量与监控流量。 |
| 可观测性数据源 | 通过 Hubble 暴露 eBPF 采集的流日志、TCP 指标、DNS 响应等。 | 直接提供 Pod 级网络吞吐、连接数、延迟数据，用于资源画像校准。 |
容量规划关键洞察： Cilium 的 eBPF 数据面使得每个网络包的处理路径都经过内核中的 eBPF 程序。这意味着我们可以通过 eBPF Map 直接读取每个 Pod 的实时网络统计（如字节数、包数、丢包数），而不需要依赖第三方 sidecar 或用户态代理。这种内核级的数据采集方式开销极低（通常 < 1% CPU），非常适合作为持续容量规划的数据源。