3. Cilium 架构速览：核心组件关系图
Cilium 并非单一二进制，而是由多个协同工作的组件构成。理解 Cilium Agent、Cilium Operator、Cilium CNI 和 Hubble 之间的职责与数据流，是进行 Pod 资源消耗画像采集与优化的前提。下面通过架构图与表格，快速建立全局认知。
3.1 组件关系总览
下图展示了 Cilium 在 Kubernetes 集群中的核心组件部署位置及其交互关系。Cilium Agent 运行在每个节点上，通过 eBPF 程序直接管理网络策略与负载均衡；Cilium Operator 负责集群级别的控制面协调；Cilium CNI 作为 kubelet 与 Agent 之间的桥梁；Hubble 则提供可观测性数据管道。
3.2 核心组件职责速览
| 组件 | 部署模式 | 核心职责 | 与 Pod 资源消耗的关系 |
|---|---|---|---|
| Cilium Agent | DaemonSet（每节点一个） | 管理 eBPF 程序、实现网络策略、Service 负载均衡、监控端点状态 | 直接决定 eBPF 程序加载数量与复杂度，是 CPU/Mem 消耗的主要来源 |
| Cilium Operator | Deployment（通常 1~2 副本） | 处理集群级协调：IPAM、CNI 配置下发、Endpoint 同步、故障恢复 | 控制面操作，影响 API Server 负载与集群事件处理延迟 |
| Cilium CNI | 二进制插件（由 kubelet 调用） | 接收 kubelet 的 CNI ADD/DEL 请求，调用 Agent 完成 Pod 网络配置 | 影响 Pod 启动延迟，本身资源消耗极低 |
| Hubble Agent | 内嵌于 Cilium Agent | 采集 eBPF 导出的网络流事件，聚合后上报给 Hubble Relay | 流事件处理与缓存占用额外内存，高流量场景需关注 |
| Hubble Relay | Deployment（通常 1 副本） | 聚合各节点 Hubble Agent 数据，提供全局 API 查询接口 | 内存消耗与集群规模、流速率正相关 |
| Hubble UI | Deployment（可选） | 可视化展示 Hubble 数据，提供 Service Map 与流日志 | 资源消耗较低，主要用于调试与可视化 |
3.3 关键交互流程
理解组件间的数据流，有助于定位资源消耗瓶颈。以下按 Pod 生命周期梳理核心交互路径：
- Pod 创建流程：kubelet 调用 Cilium CNI 二进制 → CNI 通过 Unix Socket 请求 Cilium Agent → Agent 分配 IP、创建 veth pair、加载 eBPF 程序 → 返回成功。
- 策略更新流程：用户创建 CiliumNetworkPolicy → Cilium Operator 监听并转换为 Endpoint 变更事件 → Agent 更新本地 eBPF Map 与程序。
- 可观测性数据流：eBPF 程序捕获网络包 → Hubble Agent 从 perf ring buffer 读取事件 → 聚合后通过 gRPC 发送给 Hubble Relay → Relay 提供 API 供 Hubble UI 或
hubble observe命令查询。
优化提示： 在资源消耗画像采集阶段，重点关注 Cilium Agent 的 eBPF 程序数量与 Hubble Agent 的流事件缓存大小。这两个组件直接决定了节点级资源开销，也是后续优化章节的核心对象。
3.4 组件通信方式
各组件之间通过不同的通信机制协作，理解这些机制有助于排查性能问题：
| 通信对 | 通信方式 | 协议/接口 | 性能关注点 |
|---|---|---|---|
| kubelet ↔ Cilium CNI | 本地进程调用 | CNI 标准 stdin/stdout | 低延迟，几乎无瓶颈 |
| Cilium CNI ↔ Cilium Agent | 本地 Unix Socket | gRPC | 高并发 Pod 创建时可能成为瓶颈 |
| Cilium Agent ↔ Kubernetes API | 网络调用 | REST/gRPC | Watch 事件量影响 Agent CPU 使用 |
| Hubble Agent ↔ Hubble Relay | 网络调用 | gRPC | 流数据压缩与带宽占用 |
| Cilium Operator ↔ Kubernetes API | 网络调用 | REST | IPAM 分配频率影响 API Server 负载 |
3.5 组件关系小结
从资源消耗画像的角度，可以按以下层次记忆组件关系：
- 数据面（Data Plane）：Cilium Agent + eBPF 程序 —— 直接处理 Pod 网络流量，是 CPU 和内存消耗的核心。
- 控制面（Control Plane）：Cilium Operator + Kubernetes API —— 负责策略编排与状态同步，影响集群稳定性。
- 可观测面（Observability Plane）：Hubble Agent + Hubble Relay + Hubble UI —— 提供数据采集与可视化，内存消耗随流量线性增长。