Cilium 架构基础：组件、数据面转发路径与资源消耗宏观来源
Cilium 的架构设计围绕 控制面 与 数据面 分离的原则展开。理解其核心组件、数据包穿越 eBPF 程序的路径，以及资源消耗的宏观来源，是后续进行资源画像与联合优化的前提。本章将拆解这三个基础维度。
2.1 核心组件与职责
Cilium 部署在 Kubernetes 集群中时，主要由以下四个关键组件构成，它们各自承担不同的生命周期与数据面职责：
| 组件 | 部署模式 | 核心职责 | 资源消耗特征 |
|---|---|---|---|
| Cilium Agent | DaemonSet（每节点一个） | 管理 eBPF 程序加载、端点（Pod）生命周期、策略规则下发、与 Kubernetes API Server 交互 | CPU 用于策略计算与 API 监听；内存用于存储端点状态与 eBPF Map |
| Cilium Operator | Deployment（集群级） | 处理集群范围任务：IPAM（IP 地址管理）、CiliumEndpoint 垃圾回收、网络策略状态汇总 | CPU 与内存消耗相对稳定，与集群规模（节点数、Pod 数）线性相关 |
| Cilium CNI | 二进制插件（由 kubelet 调用） | 在 Pod 创建时配置网络命名空间、分配 IP、调用 Agent 进行端点注册 | 瞬时调用，几乎不产生常驻资源消耗 |
| CRD (Custom Resource Definitions) | Kubernetes API 扩展 | 定义 CiliumNetworkPolicy、CiliumEndpoint、CiliumNode 等资源，作为控制面与数据面的配置契约 | 存储于 etcd，Agent 通过 Watch 机制监听变化，产生网络与内存开销 |
关键认知： Agent 是资源消耗的“主力”，因为它直接操作 eBPF 并维护节点级状态；Operator 是集群级协调者，其资源消耗通常比 Agent 低一个数量级。
2.2 数据面转发路径：eBPF / XDP / TC
Cilium 的数据面完全构建在 eBPF 之上，根据网络栈的挂载点不同，分为 XDP（eXpress Data Path）和 TC（Traffic Control）两种主要路径。理解数据包从网卡到 Pod 的穿越过程，是定位性能瓶颈与资源消耗热点的关键。
数据面路径概览： 物理网卡 → XDP（最早 hook）→ 内核协议栈（可选）→ TC Ingress（veth pair 主机端）→ eBPF 转发决策 → TC Egress（veth pair 容器端）→ 容器网络栈 → 应用 Socket。
下图展示了 Cilium 在节点内部的数据包转发流程，重点标注了 eBPF 程序的挂载位置：
2.3 资源消耗的宏观来源
从宏观视角看，Cilium 的资源消耗可以归纳为以下四个主要来源，它们相互关联，共同决定了节点的资源水位：
- eBPF 程序执行开销： 每个数据包经过 XDP/TC 挂载点时，都会触发 eBPF 程序的执行。程序复杂度（如策略查找、隧道封装、L7 过滤）直接影响每包 CPU 周期数。
- eBPF Map 操作与内存占用： Map 用于存储端点信息、策略规则、连接跟踪（Conntrack）表。Map 的大小与并发连接数、Pod 数量成正比，是内存消耗的主要来源。
- 控制面事件处理： Agent 监听 Kubernetes 资源变化（Pod 创建/删除、策略更新），每次事件都会触发 eBPF 程序的增量更新。频繁的事件（如大规模 Pod 滚动更新）会导致 CPU 突刺。
- 内核与用户态数据拷贝： 虽然 eBPF 减少了内核态与用户态的切换，但某些操作（如日志记录、Metrics 采集、FQDN 策略的 DNS 解析）仍涉及数据拷贝，产生额外的内存带宽与 CPU 开销。
常见误区： 很多用户只关注 eBPF 程序的“快”，而忽略了 Map 内存与事件处理带来的资源消耗。在 Pod 密度高（>100 Pod/节点）或连接数大（>10万并发）的场景下，Map 内存与事件处理往往成为瓶颈。
2.4 资源消耗的层次化分解
为了便于后续的资源画像，我们将资源消耗按层次进一步分解为 固定开销 与 动态开销：
| 层次 | 固定开销（与负载无关） | 动态开销（与负载相关） |
|---|---|---|
| Agent 进程 | 基础 Go runtime、API Watch 连接、gRPC 服务 | 策略计算、eBPF Map 更新、事件处理 |
| eBPF 程序 | 基础转发路径（如 NodePort、封装/解封装） | 策略匹配（L3/L4/L7）、Conntrack 插入/查询 |
| eBPF Map | 全局 Map（如 Node Map、Policy Map） | Per-Endpoint Map、Conntrack Map、Metrics Map |
| 内核基础设施 | veth pair 创建、网络命名空间 | 中断处理、内存拷贝、协议栈处理（非 XDP 路径） |
这种分解方式帮助我们在优化时区分“必须承担的基础成本”与“可以通过配置或架构调整优化的弹性成本”。