3. Cilium 架构概览：组件、数据路径与可观测性
Cilium 是一个基于 eBPF 的云原生网络、安全与可观测性项目。其架构设计围绕“控制面轻量、数据面高效”的原则展开，核心组件包括 Cilium Agent、Cilium Operator 和 CNI 插件。数据路径完全构建在 eBPF 之上，替代了传统的 iptables 模式，而 Hubble 则提供了深度网络可观测能力。
3.1 核心组件与职责
Cilium 采用无中心化的节点代理架构，每个 Kubernetes 节点上运行一个 Agent，Operator 负责集群级别的协调工作。
| 组件 | 部署位置 | 核心职责 | 关键技术点 |
|---|---|---|---|
| Cilium Agent | 每个节点（DaemonSet） | 管理 eBPF 程序、端点 IP 分配、网络策略下发、服务负载均衡 | 直接与 kube-apiserver 交互，通过 bpffs 挂载 eBPF 对象 |
| Cilium Operator | 集群级（Deployment） | 处理集群范围任务：IPAM 池管理、CiliumNetworkPolicy 状态、节点故障转移 | 不参与数据面，仅协调控制面逻辑 |
| CNI 插件 | 每个节点（二进制） | 响应 kubelet 的 CNI ADD/DEL 请求，将 Pod 接入 Cilium 网络 | 调用 Agent API 完成端点创建与 eBPF 程序附加 |
关键设计原则： Agent 是唯一与 eBPF 子系统交互的组件。Operator 不操作 eBPF，只负责集群级状态协调。这种分离保证了数据面的稳定性和控制面的可扩展性。
3.2 数据路径：eBPF vs iptables
Cilium 默认且推荐的数据路径是 eBPF 原生模式。与传统的 kube-proxy iptables 模式相比，eBPF 在性能、灵活性和资源消耗上具有显著优势。
性能对比要点：
- eBPF 模式：服务负载均衡在 XDP 或 TC 层完成，使用 BPF 哈希映射（O(1) 查找），无锁竞争，支持直接路由（DSR）和 Maglev 一致性哈希。
- iptables 模式：规则链遍历（O(n) 复杂度），conntrack 表全局锁，每个包需穿越多个 Netfilter 钩子，CPU 缓存污染严重。
3.3 Hubble：eBPF 驱动的可观测性层
Hubble 是 Cilium 的可观测性组件，利用 eBPF 在内核态采集网络流数据，无需修改应用程序或侵入式代理。它提供实时流量监控、服务依赖图、DNS 解析追踪和网络策略审计能力。
3.4 关键数据路径流程：Pod 到 Pod 通信
以下是一个典型 Pod 到 Pod 跨节点通信的 eBPF 数据路径步骤，展示 Cilium 如何在内核态完成转发：
- Pod A 发送数据包：veth pair 将包送入主机网络栈。
- TC ingress hook 触发：Cilium 的 eBPF 程序在网卡 TC 层拦截包，执行
tail_call跳转到策略查找逻辑。 - 端点查找：从 BPF 映射
cilium_lxc中根据源 IP 查找 Pod A 的安全标识（Security ID）。 - 策略检查：查询
cilium_policy映射，判断 Pod A 到目标 Pod B 是否允许通信。 - 服务负载均衡（可选）：如果目标 IP 是 ClusterIP，eBPF 程序执行 Maglev 一致性哈希，选择后端 Pod。
- 封装/路由：如果是跨节点通信，eBPF 程序执行 VXLAN 或 Geneve 封装（或直接路由），设置正确的源/目标 MAC。
- TC egress hook：在出方向再次执行 eBPF 程序，完成最终校验后发送到物理网卡。
工程实践注意： 在 eBPF 数据路径中，所有查找操作均使用 BPF 哈希映射（BPF_MAP_TYPE_HASH），时间复杂度为 O(1)。与 iptables 的规则链遍历不同，eBPF 程序在每次包处理中执行固定数量的映射查找，延迟可预测。这是缓存命中优化的核心基础——后续章节将深入分析 BPF 映射的哈希冲突与缓存行对齐策略。
3.5 组件通信与配置管理
Cilium 组件之间的通信遵循 Kubernetes 原生模式，所有配置通过 CRD（Custom Resource Definition）管理：
| 配置对象 | CRD 名称 | 管理组件 | 作用范围 |
|---|---|---|---|
| 网络策略 | CiliumNetworkPolicy | Agent | 命名空间/集群 |
| 服务映射 | CiliumService | Agent | 节点本地 |
| 端点标识 | CiliumEndpoint | Agent | 节点本地 |
| 节点配置 | CiliumNode | Operator | 集群 |
| IPAM 池 | CiliumPodIPPool | Operator | 集群 |
Agent 通过 Kubernetes Watch 机制监听相关 CRD 和原生资源（Pod、Service、Node）的变化，实时更新 eBPF 映射。Operator 则负责处理需要集群级协调的事件，例如 IP 池的分配与回收、节点故障时的端点迁移等。
架构优势总结：
- 无中心化瓶颈：每个节点 Agent 独立管理本地 eBPF 程序，Operator 仅处理协调逻辑。
- 数据面与控制面分离：eBPF 程序运行在内核态，不受用户态组件重启影响。
- 可观测性内置：Hubble 直接从 eBPF 数据源获取流信息，无需额外代理。
- 策略执行点前置：网络策略在 TC 层即执行，避免包进入用户态再丢弃。