3. Cilium 架构解析：Cilium Agent、Cilium Operator、Cilium CNI 插件、Hubble 组件

Cilium 的架构采用去中心化的数据面与中心化的控制面相结合的设计。理解其核心组件——Cilium Agent、Cilium Operator、Cilium CNI 插件以及Hubble——是掌握其通信机制与接口测试设计的基础。每个组件各司其职，共同构建了基于 eBPF 的高性能网络、安全与可观测性平台。

3.1 核心组件总览与职责

下表梳理了四个核心组件的部署形态与主要职责，便于快速建立全局认知。

3.2 Cilium Agent：节点级网络引擎

Cilium Agent 是运行在每个 Kubernetes 节点上的核心守护进程。它通过 gRPC 与 Kubernetes API Server 和 Cilium Operator 通信，并将网络策略、服务定义、端点信息编译为 eBPF 程序，加载到内核中。

• eBPF 程序管理：负责编译、加载、更新和卸载 XDP、TC、cgroup 等 hook 点的 eBPF 程序。
• 端点管理：维护本地节点上所有 Pod 端点的状态，包括身份标签、网络策略、服务映射。
• 服务负载均衡：实现基于 eBPF 的 kube-proxy 替代，支持 Maglev、随机等算法。
• 网络策略执行：将 Kubernetes NetworkPolicy 和 CiliumNetworkPolicy 转化为 eBPF map 中的规则。

3.3 Cilium Operator：集群级状态协调器

Cilium Operator 是集群级别的控制器，通常以 Deployment 形式运行一个或两个副本。它不直接参与数据面转发，而是负责处理需要集群全局视角的任务。

• IPAM（IP 地址管理）：根据集群配置（如 CRD-backed、ENI、Azure IPAM）分配 Pod CIDR 和 IP 地址。
• 身份管理：为每个安全身份（Security Identity）分配唯一数字 ID，并同步到所有 Agent。
• 端点修复：监控 Agent 健康状态，当 Agent 失联时进行端点状态清理或重新调度。
• CRD 控制器：监听 CiliumNetworkPolicy、CiliumEndpoint、CiliumNode 等 CRD 的变化并协调。

3.4 Cilium CNI 插件：Pod 网络接入点

Cilium CNI 插件是一个轻量级二进制文件，遵循 CNI 规范。当 kubelet 需要创建或删除 Pod 时，会调用该插件。插件本身不执行复杂的网络配置，而是通过 Unix Socket 将请求转发给本节点的 Cilium Agent。

// CNI ADD 操作简化流程
1. kubelet 调用 cni-plugin 二进制，传入容器 ID、网络命名空间等参数。
2. cni-plugin 通过 Unix Socket 向本节点 Cilium Agent 发送 AddNetworkRequest。
3. Cilium Agent 执行：
   a. 分配 IP 地址（从本地 IPAM 池）。
   b. 创建 veth pair，一端放入 Pod 命名空间，一端接入 cilium_host bridge。
   c. 加载针对该端点的 eBPF 程序（L2/L3/L4 转发、策略过滤）。
   d. 更新 eBPF map（端点映射、策略映射）。
4. cni-plugin 将结果（IP、MAC、路由）返回给 kubelet。

3.5 Hubble：可观测性与流式数据管道

Hubble 是 Cilium 的可观测性层，它利用 eBPF 在内核层面捕获网络事件，并通过 gRPC 流式传输给 Hubble Relay 和 Hubble UI。它不修改数据面，而是被动监听。

• Hubble Agent（每节点）：嵌入在 Cilium Agent 进程中，或作为独立 DaemonSet 运行。负责从 eBPF map 和 perf event 中读取流日志、丢弃事件、DNS 响应等。
• Hubble Relay（集群级）：聚合所有 Hubble Agent 的数据，提供集群范围的查询接口（gRPC）。
• Hubble UI：基于 Relay 的 Web 界面，展示服务依赖图、流量拓扑、策略审计日志。
• Hubble Metrics：以 Prometheus 格式暴露网络指标，如每秒包数、丢包率、TCP 连接数。

3.6 组件间通信架构图

下图展示了四个核心组件之间的通信关系与数据流路径。

3.7 组件间关键交互流程

为了更清晰地理解组件协作，下面以 Pod 创建和网络策略更新两个典型场景为例，展示组件间的交互顺序。

场景一：Pod 创建时的网络接入流程

1. kubelet 调用 Cilium CNI 插件（ADD 命令）。
2. CNI 插件通过 Unix Socket 向本节点 Cilium Agent 发送请求。
3. Cilium Agent 从本地 IPAM 池分配 IP，创建 veth pair，配置网络命名空间。
4. Cilium Agent 加载针对该 Pod 的 eBPF 程序（L2 转发、策略过滤）。
5. Cilium Agent 将端点信息上报给 Cilium Operator（通过 gRPC 或 Kubernetes API）。
6. Cilium Operator 更新集群端点状态，并同步身份信息到其他节点。
7. Hubble Agent 开始捕获该 Pod 的网络流日志。

场景二：网络策略更新流程

1. 用户创建/更新 CiliumNetworkPolicy CRD。
2. Cilium Operator 监听到 CRD 变化，解析策略并计算受影响的身份。
3. Cilium Operator 将策略变更事件推送给所有相关的 Cilium Agent。
4. 每个 Cilium Agent 重新编译 eBPF 策略程序，更新 eBPF map（如 cilium_policy map）。
5. Cilium Agent 确认策略生效后，返回 ACK 给 Operator。
6. Hubble 记录策略变更审计日志，并更新服务依赖图。

3.8 组件接口清单与测试策略

下表汇总了各组件的关键接口及其在接口测试中的验证重点。