2. Cilium 架构核心组件：Agent、Operator、CNI 插件、Hubble 与 KVStore（etcd）的角色与交互流程
Cilium 基于 eBPF 实现网络、可观测性与安全能力，其架构由多个分布式组件构成。理解每个组件的职责以及它们之间的交互流程，是诊断性能瓶颈的前提。本章将逐一拆解 Agent、Operator、CNI 插件、Hubble 与 KVStore（etcd） 的核心角色，并梳理其数据流与控制流。
2.1 组件角色总览
下表概括了五大核心组件在 Cilium 集群中的定位与主要职责：
| 组件 | 部署形态 | 核心职责 | 关键资源消耗点 |
|---|---|---|---|
| Agent | DaemonSet（每节点一个） | 管理 eBPF 程序、端点（Endpoint）生命周期、网络策略执行、服务负载均衡 | CPU（eBPF 编译/加载）、内存（BPF Map 大小）、与 API Server 通信 |
| Operator | Deployment（通常 1~2 副本） | 集群级状态协调：IPAM、Service 与 EndpointSlice 同步、身份管理（Identity） | API Server 请求频率、etcd 读写负载 |
| CNI 插件 | 二进制文件（由 kubelet 调用） | Pod 网络接入：分配 IP、配置网络命名空间、调用 Agent 创建端点 | 执行延迟（毫秒级）、与 Agent 通信的 gRPC 连接 |
| Hubble | DaemonSet + Deployment | 网络流量的可观测性：流日志、指标暴露、服务依赖图 | 内存（流缓冲区）、CPU（数据包解析）、存储（持久化流日志） |
| KVStore（etcd） | 外部集群或独立部署 | 存储集群共享状态：Identity、Service、Node 映射、IPAM 池 | 网络延迟、磁盘 IOPS、请求 QPS |
2.2 组件交互流程与架构图
下图展示了 Cilium 各组件之间的控制面与数据面交互关系。其中实线代表控制流（API 调用、gRPC、事件通知），虚线代表数据流（eBPF 程序处理的数据包路径）。
2.3 组件角色深度解析
2.3.1 Cilium Agent
Agent 是运行在每个节点上的守护进程，是 Cilium 最核心的执行单元。它通过 gRPC 与 kubelet 的 CNI 插件通信，负责为 Pod 创建网络端点（Endpoint），并将网络策略、服务负载均衡规则编译为 eBPF 程序加载到内核。
- 端点管理：维护本地节点上所有 Pod 的 Endpoint 对象，包括 IP、MAC、安全标识（Security Identity）。
- eBPF 生命周期：编译、加载、卸载 eBPF 程序（如
bpf_lxc、bpf_overlay、bpf_xdp）。 - 策略执行：监听 Kubernetes NetworkPolicy 与 CiliumNetworkPolicy，实时更新 BPF Map。
- 服务负载均衡：将 ClusterIP/NodePort/LoadBalancer 规则写入 BPF Map，实现内核态转发。
cilium_agent_process_cpu_seconds_total 指标，并考虑调整 --bpf-compile-debug 参数以降低编译开销。
2.3.2 Cilium Operator
Operator 是集群级别的控制器，负责处理需要全局视角的任务。它通常以 Deployment 形式运行 1~2 个副本，通过 Leader Election 保证高可用。
- IPAM（IP 地址管理）：从集群 IP 池中为节点分配 PodCIDR，回收已释放的 IP。
- Identity 同步：管理安全标识（Security Identity）的分配与回收，确保跨节点策略一致性。
- Service 与 EndpointSlice 同步：将 Kubernetes Service 变化同步到 KVStore，供 Agent 消费。
- 故障恢复：检测并修复集群状态不一致，如残留的 Endpoint 或 Identity。
2.3.3 CNI 插件
CNI 插件是一个轻量级二进制文件，由 kubelet 在创建 Pod 时调用。它的执行路径必须极快，因为 kubelet 会阻塞等待 CNI 返回结果。
# CNI 插件调用流程（简化）
1. kubelet 调用 CNI 插件（cilium-cni）
2. CNI 插件解析 Pod 的 annotation 与网络配置
3. CNI 插件通过 gRPC 请求本地 Agent 创建 Endpoint
4. Agent 分配 IP、配置 veth pair、加载 eBPF 程序
5. CNI 插件返回网络接口信息给 kubelet
6. Pod 启动，网络就绪cilium-cni 的超时时间从默认的 30s 适当延长至 60s，并确保 Agent 有足够的 CPU 余量。
2.3.4 Hubble
Hubble 是 Cilium 的可观测性层，由两个子组件构成：
- Hubble Relay（DaemonSet）：在每个节点上运行，从 Agent 的 eBPF 程序获取流日志，聚合后暴露 gRPC 接口。
- Hubble UI（Deployment）：提供 Web 界面，展示服务依赖图、流量拓扑与策略审计。
Hubble 本身不参与数据面转发，但会消耗额外的内存来缓存流日志。在性能敏感场景下，可以调整 --hubble-event-buffer-capacity 参数来控制缓冲区大小。
2.3.5 KVStore（etcd）
KVStore 是 Cilium 的集群状态存储后端，默认使用 etcd。它存储以下关键数据：
| 数据类别 | Key 示例 | 说明 |
|---|---|---|
| Identity | cilium/state/identities/v1/id/12345 |
安全标识与标签的映射 |
| Service | cilium/state/services/v1/default/my-service |
Kubernetes Service 的 Cilium 表示 |
| Node 映射 | cilium/state/nodes/v1/ip-10-0-0-1 |
节点 IP 与 Cilium 内部标识的映射 |
| IPAM 池 | cilium/state/ipam/v1/default/10.0.0.0/24 |
IP 地址分配状态 |
Agent 和 Operator 都会监听 KVStore 的变化。如果 etcd 集群出现延迟或分区，会导致 Identity 分配超时、策略更新滞后，进而影响网络连通性。
2.4 交互流程总结
下图以 Pod 创建事件为例，展示各组件之间的完整交互时序：
通过以上分析可以看出，Cilium 的组件设计遵循了“数据面本地化、控制面集中化”的原则。Agent 负责本地快速响应，Operator 处理全局协调，KVStore 提供状态持久化与共享。在 Serverless 平台中，Pod 密度高、创建销毁频繁，任何组件的性能退化都会被放大，因此需要针对每个组件建立独立的监控与调优策略。