3. Cilium 架构概览：组件、数据路径与 eBPF 挂钩点
Cilium 是一个基于 eBPF 的云原生网络、安全与可观测性项目。理解其核心组件、数据流转路径以及 eBPF 挂钩点的分布，是分析缓存命中瓶颈的前提。本章从架构视角拆解 Cilium 的运行骨架。
3.1 核心组件与职责
Cilium 采用无 DaemonSet + 中心化 Operator 的混合架构，各组件分工明确：
| 组件 | 部署模式 | 核心职责 | 关键资源 |
|---|---|---|---|
| Cilium Agent | DaemonSet（每节点一个） | 管理 eBPF 程序加载、端点 IP 分配、策略下发、服务映射 | eBPF Maps、BPF Programs、NodeConfig |
| Cilium Operator | Deployment（通常 1~2 副本） | 集群级协调：CIDR 分配、身份管理、故障恢复、CRD 同步 | ClusterPool、Identity、CRD |
| Cilium CNI Plugin | 二进制插件（由 kubelet 调用） | 容器网络命名空间创建、接口配置、IP 分配触发 | CNI 配置、Loopback 接口 |
| Cilium CLI / Hubble | 用户空间工具 | 监控、抓包、策略验证、流日志查询 | gRPC 服务、Hubble 流 |
关键点： Agent 是 eBPF 程序的“加载器”和“状态同步器”，Operator 负责集群级资源协调，CNI 插件仅做初始化触发。缓存命中瓶颈主要发生在 Agent 与 eBPF Maps 的交互路径上。
3.2 数据路径：从 Pod 到 Pod 的完整流转
下图展示了 Cilium 在 Overlay（VXLAN）模式下，两个跨节点 Pod 通信的完整数据路径与 eBPF 挂钩点分布：
性能观察： 数据路径上每经过一个 eBPF 挂钩点，都会执行一次或多次 BPF 程序。这些程序通常需要查询
cilium_ct4、cilium_lb4_services、cilium_policy 等 eBPF Maps。Map 查找的命中率直接影响转发延迟。
3.3 关键 eBPF 挂钩点详解
Cilium 在数据路径上注册了多个 eBPF 挂钩点，每个挂钩点对应不同的网络处理阶段：
| 挂钩点 | 挂载位置 | 触发时机 | 主要功能 | 缓存压力 |
|---|---|---|---|---|
| XDP (eXpress Data Path) | 物理网卡驱动层 | 数据包到达网卡，SKB 分配前 | 早期过滤、DDoS 防护、负载均衡 | 低（仅查 LB Map） |
| TC Ingress (入方向) | veth 或物理网卡 | 数据包进入网络协议栈前 | 策略执行、连接跟踪、VXLAN 解封装 | 高（CT、Policy Map） |
| TC Egress (出方向) | veth 或物理网卡 | 数据包离开网络协议栈后 | 策略执行、VXLAN 封装、NAT | 高（CT、NAT Map） |
| cgroup/skb | cgroupv2 层级 | Socket 操作（connect/sendmsg） | Socket-level 策略、带宽管理 | 中（Socket Map） |
| Tracepoint / Kprobe | 内核函数 | 内核事件触发 | 可观测性、Hubble 流捕获 | 低（仅事件采样） |
瓶颈预警： TC Ingress 和 TC Egress 是缓存命中的主要战场。当 Pod 密度高、策略规则多、连接数大时，
cilium_ct4（连接跟踪表）和 cilium_policy（策略表）的查找效率会急剧下降，导致 CPU 开销飙升和转发延迟抖动。
3.4 Agent 与 eBPF Maps 的交互模式
Cilium Agent 通过 bpf() 系统调用与内核中的 eBPF Maps 交互，主要操作包括：
- Map 创建/更新： 当新 Pod 启动或策略变更时，Agent 更新
cilium_lxc（端点信息）、cilium_policy（策略规则）等 Maps。 - Map 查找（用户态）： Agent 定期从
cilium_ct4读取连接跟踪条目，用于监控和 GC。 - Map 删除： Pod 销毁或策略移除时，Agent 清理对应的 Map 条目。
这种交互模式存在一个关键瓶颈：用户态与内核态的上下文切换。每次 bpf() 系统调用都涉及 TLB 刷新、权限检查、Map 锁竞争。当集群规模大、变更频繁时，Agent 的 Map 更新操作可能成为数据路径的间接瓶颈。
缓存命中瓶颈的根源： 数据路径上的 BPF 程序（TC/XDP）在每次包处理时都会对 eBPF Maps 执行查找操作。这些查找是纯内核态的哈希表或 LPM 树遍历，本身很快（纳秒级）。但当 Map 条目数超过 L1/L2 缓存容量时，查找会退化为内存访问（几十纳秒到几百纳秒），在高 PPS（每秒包数）场景下累积为显著的延迟开销。
3.5 架构总结与瓶颈定位
从架构角度看，Cilium 的缓存命中瓶颈主要集中在以下三个层面：
- eBPF Map 设计层面： 连接跟踪表（CT Map）和服务映射表（LB Map）的哈希桶分布、键值大小、预分配策略直接影响查找效率。
- 数据路径挂钩点层面： TC Ingress 挂钩点承担了策略查找 + 连接跟踪 + 服务转发三重压力，是缓存争抢最激烈的路径。
- Agent 同步层面： Agent 对 Maps 的批量更新操作可能引发内核锁竞争，间接影响数据路径的查找性能。