3. Cilium 基础架构：Cilium Agent、Cilium Operator、eBPF 数据路径、CNI 插件原理
Cilium 的架构设计围绕 eBPF（extended Berkeley Packet Filter）展开，通过轻量级的 Agent 和 Operator 组件，将网络、可观测性与安全策略直接注入 Linux 内核。理解其核心组件与数据路径，是后续配置网络策略与流水线集成的基础。
3.1 核心组件概览
Cilium 在 Kubernetes 集群中主要包含两大运行时组件：Cilium Agent（DaemonSet）与 Cilium Operator（Deployment）。它们分工明确，共同维护集群的网络状态。
| 组件 | 部署模式 | 核心职责 | 关键行为 |
|---|---|---|---|
| Cilium Agent | DaemonSet（每节点一个） | 管理本地 eBPF 程序、实现 CNI 插件、执行网络策略 | 监听 Kubernetes API，将 Pod 事件转化为 eBPF 映射与程序 |
| Cilium Operator | Deployment（通常 1-2 副本） | 集群级协调、处理 IPAM、Service 负载均衡、故障恢复 | 处理节点故障迁移、CIDR 分配、与 Kubernetes Service 控制器交互 |
| KV Store（可选） | etcd / CRD-backed | 存储集群网络状态与身份标识 | 大规模集群中用于跨节点同步，小集群可依赖 CRD 免去外部存储 |
架构要点：Agent 是“执行者”，负责本节点数据面；Operator 是“协调者”，负责控制面全局逻辑。两者通过 Kubernetes CRD 或 etcd 交换状态。
3.2 Cilium Agent 与 CNI 插件原理
当 kubelet 请求创建 Pod 时，Cilium 的 CNI 插件（cilium-cni）被调用。该插件不直接配置网络，而是通过 gRPC 调用本节点的 Cilium Agent 完成实际工作。
- CNI 调用入口： kubelet 调用
cilium-cni二进制，传入容器 ID、网络命名空间等参数。 - Agent 委托： CNI 插件将请求转发给本地 Agent 的 gRPC 端点。
- 接口创建： Agent 创建 veth pair，一端放入 Pod 网络命名空间（
lxc接口），另一端留在主机（lxcXXXX）。 - eBPF 加载： Agent 为 Pod 分配 IP 地址，并将对应的 L2/L3 转发规则、策略规则编译为 eBPF 程序，附加到主机端的 veth 或
cilium_host接口。 - 身份标识： Agent 根据 Pod 的标签计算安全身份（Security Identity），写入 eBPF 映射，供后续策略匹配使用。
# 典型 CNI 配置片段（/etc/cni/net.d/05-cilium.conf）
{
"cniVersion": "0.3.1",
"name": "cilium",
"type": "cilium-cni",
"enable-debug": false
}
3.3 eBPF 数据路径详解
Cilium 的数据路径完全构建在 eBPF 之上，绕过了传统的 iptables 和内核网络栈的复杂路径。数据包从 Pod 发出到对端 Pod 或外部服务，经历以下关键钩子点：
- TC（Traffic Control）入口： 数据包从 Pod 的 veth 进入主机，触发
tc ingress钩子上的 eBPF 程序（bpf_lxc）。 - 策略执行： eBPF 程序查询
cilium_ct（连接跟踪）和cilium_policy映射，判断是否允许该流量。若允许，则执行转发决策。 - 封装/路由： 根据目标 IP 判断：同节点 Pod 直接通过 veth 转发；跨节点 Pod 则通过 VXLAN/Geneve 隧道或直接路由（Native Routing）发送。
- TC 出口： 数据包离开主机物理接口前，触发
tc egress钩子，执行源 NAT（如果流量出集群）或 Service 负载均衡。
性能优势： eBPF 数据路径避免了 iptables 的线性规则遍历和上下文切换，在延迟和吞吐量上接近原生内核转发性能。Cilium 在 2023 年 CNCF 基准测试中，P99 延迟比 iptables 模式降低约 40%。
3.4 Cilium Operator 与集群协调
Operator 负责集群级别的控制面任务，确保 Agent 之间的状态一致：
| 功能模块 | 说明 | 依赖 |
|---|---|---|
| IPAM（IP 地址管理） | 从集群 CIDR 中分配 PodCIDR 给新节点，回收已删除节点的 IP 块 | Kubernetes Node 对象、CRD |
| Service 负载均衡 | 为 ClusterIP/NodePort/LoadBalancer 类型 Service 生成 eBPF 转发规则 | Kubernetes Service/EndpointSlice |
| 身份管理 | 维护全局安全身份与标签的映射关系，下发到各节点 Agent | CiliumIdentity CRD |
| 故障恢复 | 当节点失联时，重新分配其上的 Pod IP 或清理残留端点 | Lease 对象、节点心跳 |
3.5 整体架构关系图
下图展示了 Cilium 在 Kubernetes 节点上的组件布局与数据流关系：
3.6 关键设计决策
- 无 iptables 依赖： 所有转发、过滤、NAT 逻辑均通过 eBPF 实现，避免了 iptables 在规则数量增多时的性能退化。
- 身份驱动策略： 策略基于安全身份（Security Identity）而非 IP 地址，身份由 Pod 标签计算得出，支持动态扩缩容时策略自动生效。
- 可观测性内置： eBPF 程序在数据路径中直接采集指标（如丢包、延迟、TCP 状态），通过 Hubble 组件暴露，无需 sidecar 代理。
注意事项： 在
direct-routing 模式下，Cilium 要求节点之间二层可达或配置 BGP 路由；若使用隧道模式（VXLAN），则需确保 UDP 8472 端口在节点间互通。生产环境建议启用 kube-proxy-replacement 以完全绕过 kube-proxy。
3.7 组件交互时序
以下时序图展示了一个 Pod 创建事件从 API Server 到 eBPF 程序加载的完整链路：