3. Cilium 核心概念：eBPF 数据平面、Cilium Agent、Cilium Operator、CNI 插件
在深入 Cilium 与 Envoy 的联合升级链路追踪验证之前，必须清晰理解 Cilium 的四大核心组件及其协作关系。Cilium 并非单一二进制，而是一个由 eBPF 数据平面、Cilium Agent、Cilium Operator 和 CNI 插件 构成的分布式系统。每个组件承担不同职责，共同实现高性能网络、可观测性与安全策略。
3.1 核心组件总览
下表从功能定位、运行位置、生命周期三个维度对比四大核心组件：
| 组件 | 功能定位 | 运行位置 | 生命周期 |
|---|---|---|---|
| eBPF 数据平面 | 内核态网络转发、策略执行、可观测性数据采集 | Linux 内核（每个节点） | 随内核持续运行 |
| Cilium Agent | 管理 eBPF 程序、与 Kubernetes API 交互、暴露监控接口 | DaemonSet（每个节点一个 Pod） | 与节点生命周期绑定 |
| Cilium Operator | 集群级协调：身份管理、CNI 配置、故障恢复 | Deployment（通常 1~2 个副本） | 集群级常驻服务 |
| CNI 插件 | Pod 网络接入、IP 分配、网络接口配置 | kubelet 调用（每个节点） | 按需触发 |
3.2 eBPF 数据平面：内核态的核心引擎
eBPF（extended Berkeley Packet Filter）是 Cilium 的基石。Cilium 将网络策略、负载均衡、可观测性逻辑编译为 eBPF 字节码，动态注入 Linux 内核。eBPF 数据平面运行在内核态，具备以下关键能力：
- 网络转发：通过 TC（Traffic Control）或 XDP（eXpress Data Path）hook 点，实现 Pod 间、Service 后端间的数据包转发，绕过传统 iptables 遍历。
- 策略执行：在 L3/L4/L7 层实施网络策略，eBPF map 存储端点身份与策略规则，匹配效率为 O(1)。
- 可观测性：通过 kprobe/tracepoint 采集 TCP 连接、DNS 请求、HTTP 请求等事件，生成 Hubble 可观测数据。
- 负载均衡：实现 Maglev 一致性哈希或随机选择算法，替换 kube-proxy 的 iptables/IPVS 模式。
3.3 Cilium Agent：节点级控制面
Cilium Agent 以 DaemonSet 方式在每个 Kubernetes 节点上运行，是连接 Kubernetes 控制面与 eBPF 数据平面的桥梁。其核心职责包括：
- eBPF 程序管理：编译、加载、更新、卸载节点上的 eBPF 程序。
- 端点管理：监听 Kubernetes Pod 变化，维护本地端点（Endpoint）信息，写入 eBPF map。
- 策略同步：从 Kubernetes API Server 获取 NetworkPolicy 和 CiliumNetworkPolicy，转换为 eBPF map 条目。
- 监控暴露：提供 Prometheus 指标（/metrics）、Hubble gRPC 流（/health）、pprof 调试接口。
- Envoy 管理：当启用 L7 策略时，Agent 负责管理本地 Envoy 代理的生命周期与配置下发。
3.4 Cilium Operator：集群级协调者
Cilium Operator 是集群范围的控制器，不直接参与数据平面转发，但负责全局状态管理：
- 身份管理：为每个安全敏感的身份（Security Identity）分配唯一数字 ID，并同步到所有节点的 eBPF map。
- CNI 配置：在集群初始化时写入 CNI 配置文件（/etc/cni/net.d/），确保 kubelet 能正确调用 Cilium CNI 插件。
- 故障恢复：监控 Agent 健康状态，触发重新加载或重启。
- 资源清理：回收已删除节点的身份和端点残留数据。
3.5 CNI 插件：Pod 网络接入点
Cilium 实现了标准的 CNI（Container Network Interface）插件，由 kubelet 在创建 Pod 时调用。CNI 插件执行以下步骤：
- IP 分配：从 Cilium 的 IPAM（IP Address Management）模块获取可用 IP 地址。
- 网络接口创建：创建 veth pair，一端放入 Pod 网络命名空间，另一端挂载到主机。
- eBPF 端点注册：通知 Cilium Agent 新 Pod 的元数据（命名空间、标签、IP），Agent 将其写入 eBPF map。
- 路由配置：设置 Pod 网络命名空间内的默认路由和主机侧的路由规则。
CNI 插件本身是轻量级二进制文件，不维护持久状态，所有状态由 Agent 和 Operator 管理。
3.6 组件协作流程（内联 SVG）
下图展示了一个 Pod 创建过程中，CNI 插件、Agent、Operator 与 eBPF 数据平面的协作流程：
3.7 组件在升级中的角色差异
在 Cilium 与 Envoy 联合升级的链路追踪验证中，不同组件对升级的影响程度不同：
| 组件 | 升级影响范围 | 链路追踪数据影响 | 升级策略建议 |
|---|---|---|---|
| eBPF 数据平面 | 节点级，影响该节点所有 Pod 网络 | 可能丢失正在采集的 Hubble 事件流 | 使用 bpf_link 原子替换，逐节点升级 |
| Cilium Agent | 节点级，影响该节点策略与监控 | Agent 重启期间 Hubble gRPC 流中断 | 滚动更新 DaemonSet，保留旧连接直到新 Agent 就绪 |
| Cilium Operator | 集群级，影响身份分配与 CNI 配置 | 身份 ID 变更可能导致追踪标签不一致 | 先升级 Operator，确保身份映射兼容 |
| CNI 插件 | 仅影响新创建 Pod | 不影响已有追踪流 | 二进制替换，无需重启 |
3.8 组件架构关系（内联 SVG）
下图从架构分层角度展示 Cilium 组件与 Kubernetes 及 Envoy 的关系：
- Agent 是用户态核心，管理 eBPF 程序并与 Kubernetes API 双向同步。
- Operator 不直接操作 eBPF，但控制身份和 CNI 配置等集群级资源。
- Envoy 作为独立进程运行，由 Agent 管理配置，但数据路径经过 eBPF 转发。
- CNI 插件是 kubelet 与 Cilium 之间的桥梁，仅在 Pod 创建时触发。
3.9 与链路追踪验证的关联
理解这四个核心概念对于后续章节的链路追踪验证至关重要：
- eBPF 数据平面 是 Hubble 可观测性数据的来源，升级时需确保 eBPF 程序版本兼容，否则追踪事件可能丢失或格式错误。
- Cilium Agent 管理 Hubble gRPC 服务，升级 Agent 会导致追踪流短暂中断，需要设计重连机制。
- Cilium Operator 管理身份 ID，升级后身份 ID 可能重新分配，导致追踪标签（如 source_identity）前后不一致。
- CNI 插件 影响新 Pod 的 IP 分配，升级期间新 Pod 可能无法获取 IP，影响追踪拓扑的完整性。