Cilium 架构速览：数据平面、控制平面与关键组件交互

Cilium 的架构可以清晰地划分为数据平面和控制平面两个核心层次。数据平面基于 eBPF 在内核中高效执行网络策略与转发；控制平面则由 Cilium Agent、Operator 以及 Hubble 等组件构成，负责策略下发、状态同步与可观测性。理解这两层及其关键组件的交互关系，是掌握 Cilium 运维与故障排查的基础。

1. 数据平面：eBPF 驱动的内核网络栈

Cilium 的数据平面完全构建在 eBPF（extended Berkeley Packet Filter）之上。eBPF 允许用户在 Linux 内核中安全地运行沙箱化程序，而无需修改内核源码或加载内核模块。Cilium 利用 eBPF 在数据路径的关键钩子点（如网络设备、套接字操作、XDP）注入程序，实现网络转发、负载均衡、安全策略与可观测性。

2. 控制平面：Agent 与 Operator 的协同

控制平面负责管理数据平面的状态。Cilium 的控制平面主要由两个组件构成：Cilium Agent 和 Cilium Operator。

• Cilium Agent：以 DaemonSet 形式运行在每个 Kubernetes 节点上。它通过监听 Kubernetes API Server 获取 Pod、Service、NetworkPolicy 等资源变化，并将这些高层级意图编译为 eBPF 程序，加载到所在节点的内核中。Agent 还负责与节点上的容器运行时（如 containerd）交互，管理本地端点。
• Cilium Operator：通常以 Deployment 形式运行，负责处理集群级别的任务，例如：管理 IP 地址分配（IPAM）、处理 CiliumNetworkPolicy 的集群范围校验、以及管理多集群服务网格的配置。Operator 不直接参与数据平面的数据包处理。

3. 关键组件交互关系

下图展示了 Cilium 数据平面与控制平面组件之间的核心交互流程，以及它们如何与 Kubernetes 生态集成。

4. 关键组件详解

4.1 CNI 插件

Cilium 实现了标准的 CNI（Container Network Interface）插件。当 kubelet 请求创建 Pod 时，Cilium CNI 二进制文件被调用，负责为 Pod 分配网络命名空间、配置网络接口（通常是通过 eBPF 实现的虚拟以太网设备 veth pair），并分配 IP 地址。Cilium Agent 随后会为这个新 Pod 创建对应的本地端点（Endpoint），并加载相应的 eBPF 程序。

4.2 kube-proxy 替代

Cilium 可以完全替代 kube-proxy 的功能。它通过 eBPF 在节点上实现 Service 的负载均衡，无需依赖 iptables 或 IPVS。Cilium Agent 监听 Service 和 EndpointSlice 的变化，直接在 eBPF 映射表中维护后端端点列表。当数据包到达时，eBPF 程序执行高效的哈希或随机选择，将流量转发到正确的后端 Pod。

4.3 Hubble

Hubble 是 Cilium 的可观测性层。它从 Cilium Agent 和 eBPF 数据平面收集流日志、指标和事件，并提供实时的网络流量可视化。Hubble 的核心组件包括：

• Hubble Agent：运行在每个节点上，从 Cilium Agent 获取事件并暴露本地 gRPC 服务。
• Hubble Relay：集群级别的组件，聚合所有 Hubble Agent 的数据，提供统一的查询接口。
• Hubble UI：基于 Web 的图形化界面，用于展示服务依赖关系、流量流向和策略执行情况。

5. 组件交互流程总结

下表总结了关键组件之间的交互方向与核心职责，帮助你在故障排查时快速定位问题所在。

6. 数据平面与控制平面的交互细节

为了更深入地理解故障场景，我们需要关注 Agent 如何将控制平面的意图转化为数据平面的具体行为。下图展示了这一关键转换过程。