4. Cilium 架构详解：Cilium Agent、Cilium Operator、Cilium CNI 插件、eBPF 数据路径

在生产环境中实现 拉取加速 SLO，必须深入理解 Cilium 的核心组件及其协作方式。Cilium 并非单一二进制，而是由 Cilium Agent、Cilium Operator、Cilium CNI 插件 以及底层的 eBPF 数据路径 构成的分布式系统。本章将逐一拆解这些组件，并揭示它们如何共同实现高性能网络与安全策略。

4.1 整体架构概览

下图展示了 Cilium 在 Kubernetes 集群中的核心组件布局与数据流关系。理解这张图是掌握后续 SLO 调优的基础。

Cilium 核心组件架构图 Cilium 核心组件架构图 Kubernetes 控制面 (API Server / etcd) 存储 Pod、Service、Endpoint、NetworkPolicy 等资源 Cilium Operator 集群级协调：身份管理、CNP 聚合、IPAM Kubernetes 工作节点 (Node) Cilium Agent DaemonSet (每节点一个) Cilium-CNI 插件 二进制调用链 eBPF 程序 TC / XDP / cgroup Agent 通过 bpftool / libbpf 加载和管理 eBPF eBPF 数据路径 (Datapath) 网络数据包处理：转发、负载均衡、策略执行、可观测性 Pod A (App) Pod B (App)

4.2 Cilium Agent：节点级控制平面

Cilium Agent 以 DaemonSet 形式运行在每个 Kubernetes 工作节点上，是节点上最核心的进程。它负责与 Kubernetes API Server 交互，并将网络和安全意图转化为节点本地的 eBPF 程序。

关键职责：
  • API 监听与状态同步： 通过 Informer 机制监听 Pod、Service、Endpoint、NetworkPolicy 等资源变化。
  • eBPF 程序生命周期管理： 编译、加载、附加和卸载 eBPF 程序到网络接口、cgroup 等挂载点。
  • IP 地址管理 (IPAM)： 为节点上的 Pod 分配 IP 地址，支持 CRD、Kuberenetes HostScope、AWS ENI、Azure 等多种模式。
  • 服务负载均衡： 将 Kubernetes Service 转换为 eBPF 中的 BPF_MAP_TYPE_HASH 映射，实现高性能南北向和东西向流量转发。
  • 网络策略执行： 将 CiliumNetworkPolicy (CNP) 和 Kubernetes NetworkPolicy 编译为 eBPF 中的查找表，在数据路径上执行 L3/L4/L7 策略。
  • 可观测性数据导出： 通过 Hubble 组件收集流日志、指标和事件，供监控和排障使用。

4.3 Cilium Operator：集群级协调器

Cilium Operator 是集群级别的控制器，通常以 Deployment 形式运行（建议至少 2 副本以保证高可用）。它不直接参与数据路径，而是负责全局协调任务。

功能模块 说明 对 SLO 的影响
身份管理 (Identity) 为每个安全相关的端点（Pod 或 IP）分配全局唯一的数字身份 (Security Identity)。 身份分配延迟直接影响新 Pod 的网络就绪时间。
CNP 聚合 将集群范围内的 CiliumNetworkPolicy 规则聚合，并分发到各节点的 Agent。 策略变更的传播速度影响安全策略生效的 SLO。
IPAM 池管理 管理全局 IP 地址池，为节点分配 IP 子网。 IP 池耗尽或分配缓慢会导致 Pod 创建失败。
KVStore 维护 当使用 etcd 作为后端时，负责维护集群状态的一致性。 KVStore 的性能瓶颈会拖慢整个集群的协调速度。
SRE 视角： Operator 的 身份管理 和 CNP 聚合 是影响拉取加速 SLO 的关键路径。如果 Operator 出现性能瓶颈，新 Pod 启动后可能长时间无法获得正确的网络策略，导致拉取流量被误拦截或绕行。

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

Cilium CNI 插件是一个轻量级二进制文件，遵循 Kubernetes CNI 规范。当 kubelet 需要创建或删除 Pod 网络时，会调用该插件。

工作流程：

  1. ADD 操作： kubelet 调用 Cilium CNI 二进制，传入 Pod 的命名空间、名称、Sandbox ID 等信息。
  2. 接口创建： 插件在 Pod 的网络命名空间中创建 veth pair，一端放入 Pod，另一端连接到主机的 cilium_host 或 lxc 接口。
  3. IP 分配： 插件向本地的 Cilium Agent 请求 IP 地址（通过 Unix Socket 通信）。
  4. eBPF 挂载： Agent 为新的 Pod 接口加载对应的 eBPF 程序，用于流量转发和策略执行。
  5. 路由配置： 在主机和 Pod 命名空间中配置必要的路由规则。
性能陷阱： CNI 插件的执行时间直接计入 Pod 启动延迟。在拉取加速场景中，如果 CNI 插件因等待 Agent 响应而阻塞，会显著增加镜像拉取前的网络就绪时间。建议监控 cilium_cni_duration_seconds 指标。

4.5 eBPF 数据路径：高性能内核态处理

eBPF 数据路径是 Cilium 实现高性能网络和安全的核心。Cilium Agent 将网络策略、服务转发规则等编译为 eBPF 字节码，并加载到内核的特定挂载点。

关键挂载点与功能：

挂载点 eBPF 程序类型 功能描述
XDP (eXpress Data Path) BPF_PROG_TYPE_XDP 在网卡驱动层处理数据包，实现最早的丢包、转发或重定向。适用于 DDoS 防护和高压负载均衡。
TC (Traffic Control) Ingress/Egress BPF_PROG_TYPE_SCHED_CLS 在协议栈处理前后进行过滤、转发、封装/解封装。是 Cilium 默认的数据路径，支持所有高级功能。
cgroup/skb BPF_PROG_TYPE_CGROUP_SKB 在 cgroup 级别对进出 Pod 的数据包进行策略控制，用于实现 NetworkPolicy。
cgroup/sock BPF_PROG_TYPE_CGROUP_SOCK 在 socket 创建、连接、绑定等操作时执行策略，用于实现基于身份的安全策略。

数据路径处理流程（以 Pod 间通信为例）：

  1. Pod A 发送数据包到 veth 对端（主机侧接口）。
  2. 主机侧接口上的 TC Ingress eBPF 程序 被触发。
  3. 程序查找 BPF_MAP（包含服务映射、策略映射、身份映射），决定数据包的处理方式：
    - 转发： 直接重定向到目标 Pod 的接口。
    - 负载均衡： 修改目标 IP 和端口为后端 Pod 地址。
    - 加密： 通过 WireGuard 或 IPsec 进行加密。
    - 丢弃： 如果违反网络策略，直接丢包。
  4. 处理后的数据包通过 TC Egress eBPF 程序 发送到目标 Pod 的接口。
拉取加速 SLO 关键点：
  • XDP 模式： 如果节点网卡支持，启用 XDP 卸载可以大幅降低数据包处理延迟，对镜像仓库的大流量拉取有明显加速效果。
  • eBPF Map 大小： 确保 cilium_bpf_map_max 配置足够大，避免在高密度 Pod 场景下出现 map 溢出，导致策略失效或转发错误。
  • 直接路由 (Direct Routing)： 相比隧道模式（VXLAN/Geneve），直接路由模式减少了一次封装/解封装开销，能提升拉取吞吐量。

4.6 组件协作流程总结

以下表格总结了在 创建新 Pod 并开始 拉取镜像 的场景中，各组件如何协作：

步骤 组件 动作 对拉取 SLO 的影响
1 Kubernetes API Server 创建 Pod 对象 调度延迟
2 Cilium Operator 为 Pod 分配 Security Identity 身份分配延迟
3 kubelet → Cilium CNI 调用 CNI ADD CNI 插件执行时间
4 Cilium Agent 分配 IP、加载 eBPF 程序 Agent 响应时间
5 eBPF 数据路径 处理 Pod 网络流量 数据包转发延迟、吞吐量
6 Hubble (Agent 内) 生成网络流日志 可观测性开销（通常可忽略）

理解上述组件的职责与协作关系，是后续章节中诊断拉取性能瓶颈、优化 Cilium 配置、以及制定 SLO 指标的基础。下一章将深入探讨如何利用 Hubble 观测这些组件的行为。

← 上一章 📖 返回目录 下一章 →