Cilium 架构速览：Agent、Operator、CNI 插件、eBPF 数据路径与 Hubble 组件关系图
Cilium 是一个基于 eBPF 的云原生网络、安全与可观测性项目。理解其核心组件及协作关系，是进行调度优化与网络拓扑排查的前提。本节将拆解 Cilium 的五大关键模块：Cilium Agent、Cilium Operator、CNI 插件、eBPF 数据路径以及Hubble，并展示它们之间的交互关系。
核心组件一览
| 组件 | 部署形态 | 核心职责 | 关键接口/数据 |
|---|---|---|---|
| Cilium Agent | DaemonSet (每节点一个) | 管理 eBPF 程序、端点 IP 分配、网络策略执行、与 Kubernetes API 交互 | Kubernetes API、eBPF Map、CNI 套接字 |
| Cilium Operator | Deployment (通常 1~2 副本) | 集群级协调：CIDR 分配、身份管理、节点故障处理、CRD 状态同步 | Kubernetes API、etcd (间接) |
| CNI 插件 | 二进制文件 (由 kubelet 调用) | 将 Pod 接入 Cilium 网络，调用 Agent 完成接口创建与 IP 分配 | Unix 域套接字 (与 Agent 通信) |
| eBPF 数据路径 | 内核内 (由 Agent 加载) | 数据包转发、负载均衡、网络策略过滤、可观测性钩子 | eBPF Map、TC/XDP 钩子 |
| Hubble | DaemonSet + Deployment | 流日志采集、服务依赖图、网络性能监控、告警事件导出 | eBPF Map (perf ring buffer)、gRPC API |
组件关系与数据流
下图展示了 Cilium 各组件在 Kubernetes 集群中的部署位置与通信路径。注意 eBPF 数据路径位于内核空间，是其他所有组件的最终执行层。
组件交互详解
1. Cilium Agent：节点级大脑
- 启动流程：Agent 启动后通过 Kubernetes Watch 监听 Pod、Service、Endpoint、NetworkPolicy 等资源变化。
- eBPF 管理：将监听到的策略与端点信息编译为 eBPF 程序，通过
bpftool或cilium bpf命令加载到网络接口的 TC 或 XDP 钩子。 - CNI 协作：当 kubelet 调用 CNI 插件时，插件通过 Unix 域套接字向 Agent 请求分配 IP 并创建虚拟以太网对（veth pair）。
排查要点：如果 Pod 网络不通，首先检查
cilium status 确认 Agent 健康状态，然后查看 cilium endpoint list 确认端点标识是否正常。
2. Cilium Operator：集群级协调器
- CIDR 管理：负责集群范围的 PodCIDR 分配与回收，避免 IP 冲突。
- 身份管理：为每个安全标识（Security Identity）分配唯一 ID，并同步到所有节点的 eBPF Map。
- 故障恢复：当节点故障时，Operator 负责清理该节点上的端点状态，并触发重新调度。
3. CNI 插件：Pod 接入的桥梁
- 调用链：kubelet → CNI 插件（二进制） → Unix 套接字 → Cilium Agent → 创建 veth + 分配 IP + 加载 eBPF 程序。
- 关键参数：
cni-conf.yml中指定type: cilium-cni，并配置chaining-mode（如 generic-veth、portmap）。
4. eBPF 数据路径：内核中的执行引擎
这是 Cilium 性能优势的核心。所有数据包在进入 Pod 或节点网络栈之前，都会被 eBPF 程序处理：
- 网络策略：基于 L3/L4/L7 的允许/拒绝决策，无需 iptables 遍历。
- 负载均衡：通过 eBPF Map 实现高效的 Service 后端选择，支持 DSR（直接服务器返回）。
- 可观测性：通过 perf ring buffer 将包事件推送到 Hubble 采集器。
性能陷阱：eBPF 程序复杂度受内核限制（指令数上限 4096，辅助函数调用深度有限）。复杂的 L7 策略可能触发验证失败，需使用
cilium bpf metrics 监控指令数。
5. Hubble：可观测性层
Hubble 由两部分组成：
- Hubble Agent（DaemonSet）：在每个节点上运行，从 eBPF perf ring buffer 读取流事件，聚合后通过 gRPC 暴露。
- Hubble Relay（Deployment）：作为集群级查询入口，合并所有 Agent 的数据，提供全局服务依赖图和流日志检索。
组件通信矩阵
| 源组件 | 目标组件 | 通信协议 | 用途 |
|---|---|---|---|
| Cilium Agent | Kubernetes API | HTTPS (gRPC/HTTP) | 监听资源变更，上报端点状态 |
| Cilium Operator | Kubernetes API | HTTPS (gRPC/HTTP) | 协调 CIDR、身份、节点状态 |
| CNI 插件 | Cilium Agent | Unix 域套接字 | 请求 IP 分配与接口创建 |
| Cilium Agent | eBPF 数据路径 | bpf() 系统调用 | 加载/更新 eBPF 程序与 Map |
| eBPF 数据路径 | Hubble Agent | Perf Ring Buffer | 推送流事件与指标 |
| Hubble Agent | Hubble Relay | gRPC (mTLS) | 上报节点级流数据 |
架构设计要点总结
- 去中心化数据路径：eBPF 程序直接运行在每个节点内核中，不依赖集中式代理，避免性能瓶颈。
- 控制面与数据面分离：Agent/Operator 负责控制面逻辑，eBPF 数据路径只做快速转发与过滤。
- 可观测性内建：Hubble 直接从 eBPF 层采集数据，无需 sidecar 或 iptables 日志，开销极低。
- API 驱动：所有组件通过 Kubernetes API 或 gRPC 通信，易于集成现有监控与告警体系。