3. Cilium 架构与核心组件解析

Cilium 的架构设计围绕 eBPF（extended Berkeley Packet Filter）技术展开，将数据平面与控制平面解耦，同时提供强大的可观测性能力。理解其核心组件——Cilium Agent、Cilium Operator、CNI 插件、eBPF 数据路径以及 Hubble——是进行多租户网络调优的基础。

3.1 整体架构概览

下图展示了 Cilium 在 Kubernetes 集群中的核心组件及其交互关系。数据平面通过 eBPF 程序直接在内核中处理网络包，控制平面则负责策略下发与状态同步。

3.2 核心组件详解

3.2.1 Cilium Agent

Cilium Agent 是运行在每个 Kubernetes 节点上的守护进程（DaemonSet），是 Cilium 数据平面的核心执行者。它负责管理该节点上所有与网络相关的 eBPF 程序。

• CNI 实现：作为 CNI 插件被 kubelet 调用，为 Pod 分配 IP 地址并配置网络接口。
• eBPF 管理：编译、加载和卸载 eBPF 程序到内核，实现网络转发、负载均衡、安全策略等。
• 策略执行：监听来自 Kubernetes API Server 的网络策略（NetworkPolicy）和 CiliumNetworkPolicy，并将其转化为 eBPF 映射表。
• 身份管理：为本地 Pod 分配安全身份（Security Identity），用于后续的策略匹配。

3.2.2 Cilium Operator

Cilium Operator 是集群级别的控制平面组件，通常只运行一个副本（或高可用部署）。它不参与数据路径，而是负责全局协调任务。

3.2.3 CNI 插件

Cilium 的 CNI 插件是一个轻量级的二进制文件（cilium-cni），由 kubelet 在创建 Pod 时调用。其工作流程如下：

1. ADD 操作：kubelet 调用 CNI 插件，传入 Pod 的命名空间、名称和网络配置。
2. IP 分配：插件通过 Cilium Agent 的 API 请求 IP 地址（来自 CRD-based IPAM 或 Kubernetes Node CIDR）。
3. 接口创建：在 Pod 的网络命名空间中创建 veth 对，一端放入 Pod，另一端连接到主机的 cilium_host 网桥或直接挂载 eBPF 程序。
4. eBPF 挂载：Agent 为 Pod 的接口挂载对应的 eBPF 程序（如 cil_from_container、cil_to_container），用于流量处理和策略执行。
5. 路由注入：在 Pod 和主机路由表中添加必要的路由条目，确保流量能够到达正确的 eBPF 处理点。

3.3 eBPF 数据路径

eBPF 数据路径是 Cilium 性能优势的根本来源。它通过在内核的多个钩子点（Hook Points）注入程序，实现网络包的拦截、处理和转发。

关键 eBPF 钩子点说明：

• XDP (eXpress Data Path)：在网络驱动层之后、协议栈之前执行，适合 DDoS 防护和早期包过滤，性能极高。
• TC (Traffic Control) Ingress/Egress：在协议栈内部执行，Cilium 在此实现大部分网络策略、负载均衡（如 Maglev）和封装（VXLAN/Geneve）。
• Socket BPF：在 socket 层操作，用于 socket-level 的负载均衡和策略，减少上下文切换。

3.4 Hubble 可观测性组件

Hubble 是 Cilium 的可观测性层，利用 eBPF 程序自动捕获网络流量和事件，提供实时的服务依赖图、流量日志和指标监控。

3.4.1 Hubble 组件构成

3.4.2 多租户场景下的 Hubble 使用

在多租户环境中，Hubble 可以结合 Cilium 的身份标签进行流量过滤和审计：

# 实时观察 tenant-a 命名空间下的所有流量
hubble observe --namespace tenant-a

# 观察从 tenant-a 到 tenant-b 的流量
hubble observe --from-namespace tenant-a --to-namespace tenant-b

# 查看特定 Pod 的 DNS 查询记录
hubble observe --pod web-0 --type l7 --protocol dns

3.5 组件交互流程总结

以下表格总结了核心组件在 Pod 创建和网络策略生效过程中的交互关系：