Cilium 基础回顾：架构、核心组件与集成原理
Cilium 是基于 eBPF（extended Berkeley Packet Filter）技术的云原生网络、安全与可观测性项目。它利用 Linux 内核的 eBPF 能力，在无需修改应用程序或容器内核的情况下，为 Kubernetes 集群提供高性能的网络连接、服务负载均衡、网络策略以及可观测性。本节将回顾 Cilium 的核心架构、关键组件及其与 Kubernetes 的集成原理，为后续的准入策略移植适配奠定基础。
Cilium 整体架构
Cilium 采用控制面与数据面分离的架构。控制面负责与 Kubernetes API Server 交互、策略管理和状态同步；数据面则通过 eBPF 程序直接在内核层面执行数据包转发与策略决策。这种架构使得 Cilium 能够在不引入额外代理或 iptables 规则的情况下，实现高效的网络处理。
- 控制面-数据面分离：控制面组件（Operator、CLI）不参与数据路径，仅负责策略下发与状态管理。
- eBPF 数据面：所有数据包处理、负载均衡、策略执行均在 Linux 内核的 eBPF 虚拟机中完成，避免上下文切换。
- 身份与策略分离：基于身份（Identity）而非 IP 地址进行策略定义，适应动态调度的容器环境。
核心组件详解
Cilium 由几个关键组件构成，每个组件承担着不同的职责。理解这些组件是掌握 Cilium 工作原理的基础。
| 组件 | 部署模式 | 核心职责 | 关键说明 |
|---|---|---|---|
| Cilium Agent | DaemonSet（每个节点一个） | 管理 eBPF 程序、执行网络策略、服务负载均衡、CNI 实现 | 数据面核心，通过 gRPC 与 kubelet 交互 |
| Cilium Operator | Deployment（通常 1-2 副本） | 集群级状态管理、身份分配、端点清理、多集群服务 | 控制面核心，不参与数据路径 |
| Cilium CNI 插件 | 二进制文件（节点本地） | 容器网络接口实现，负责 Pod 网络接入 | 由 kubelet 调用，委托给 Agent 处理 |
| Hubble | DaemonSet + Deployment | 网络可观测性、流日志、服务依赖图 | 基于 eBPF 的流量捕获，可选组件 |
| Cilium CLI | 命令行工具 | 集群状态检查、策略验证、故障排查 | 管理工具，不常驻运行 |
Cilium Agent：数据面的核心
Cilium Agent 是运行在每个 Kubernetes 节点上的 DaemonSet，是 Cilium 数据面的核心执行者。它负责将 Kubernetes 资源（Pod、Service、NetworkPolicy）转换为 eBPF 程序并加载到内核中。
- 监听 Kubernetes 事件：通过 Informer 机制监听 Pod、Service、Endpoint、NetworkPolicy 等资源变化。
- 身份分配：为每个 Pod 分配基于标签的安全身份（Security Identity），用于策略匹配。
- eBPF 程序生成：根据当前集群状态动态生成 eBPF 程序（如 TC、XDP、cgroup 程序）。
- 内核加载：通过
bpftool或cilium bpf命令将 eBPF 程序加载到内核中。 - 策略执行：在数据路径中实时执行网络策略，允许或拒绝流量。
Cilium Operator：集群状态的管理者
Cilium Operator 是集群级别的控制面组件，负责处理那些不需要在每个节点上执行的任务。它通常以 Deployment 形式部署，具有高可用性。
- 身份管理：维护全局身份（Identity）到标签的映射关系，确保跨节点身份一致性。
- 端点清理：定期清理已终止 Pod 的残留端点信息，防止身份泄漏。
- 多集群服务：在 Cluster Mesh 场景下，负责跨集群服务发现与策略同步。
- 资源状态协调：监控 CiliumNetworkPolicy、CiliumClusterwideNetworkPolicy 等 CRD 资源的状态。
Cilium CNI 插件：Pod 网络的接入点
Cilium 实现了标准的 CNI（Container Network Interface）插件，当 kubelet 创建 Pod 时，会调用该插件为 Pod 配置网络。Cilium 的 CNI 插件是一个轻量级二进制文件，它不直接执行网络配置，而是将请求转发给本地的 Cilium Agent。
// CNI 插件调用流程（简化）
1. kubelet 调用 Cilium CNI 二进制（ADD 命令）
2. CNI 二进制解析 stdin 中的 CNI 配置
3. CNI 二进制通过 Unix Socket 向本地 Cilium Agent 发送 gRPC 请求
4. Cilium Agent 执行：
a. 创建 veth pair（一端在 Pod 网络命名空间，一端在主机）
b. 分配 IP 地址（基于 IPAM 模块）
c. 分配安全身份（基于 Pod 标签）
d. 加载 eBPF 程序到 veth 端点
5. CNI 二进制返回网络配置结果给 kubelet与 Kubernetes 的集成原理
Cilium 深度集成 Kubernetes，利用其原生 API 和 CRD 扩展机制实现网络策略和服务管理。其集成原理主要体现在以下几个方面：
集成关键机制
| 集成机制 | 实现方式 | 作用 |
|---|---|---|
| 资源监听 | 使用 client-go Informer 监听 Kubernetes 原生资源 | 实时感知 Pod、Service、Endpoint 变化，触发 eBPF 程序更新 |
| CRD 扩展 | 定义 CiliumNetworkPolicy、CiliumClusterwideNetworkPolicy 等 CRD | 提供比原生 NetworkPolicy 更丰富的策略能力（L7、DNS、CIDR） |
| 身份映射 | 基于 Pod 标签计算安全身份（Security Identity） | 实现身份而非 IP 的策略匹配，适应 Pod 动态调度 |
| CNI 集成 | 实现标准 CNI 插件，通过 gRPC 与 Agent 通信 | 确保 Pod 创建时自动接入 Cilium 网络 |
| Service 处理 | 使用 eBPF 实现 kube-proxy 替代（kube-proxy replacement） | 高性能服务负载均衡，无需 iptables 或 IPVS |
- Cilium 默认接管集群的 Service 处理，如果集群中同时运行 kube-proxy，需要确保两者不冲突（建议启用 kube-proxy replacement 并禁用 kube-proxy）。
- CRD 策略（CiliumNetworkPolicy）与原生 NetworkPolicy 可以共存，但优先级规则需要明确：Cilium 策略默认允许，原生策略默认拒绝。
- 身份分配依赖于 Pod 标签，确保标签设计合理，避免身份爆炸（Identity Bloat）。
数据路径概览
Cilium 的数据路径完全基于 eBPF，避免了传统 iptables 或代理模式的性能开销。当数据包到达节点时，eBPF 程序在内核中直接执行策略检查和转发决策。
数据包处理流程（简化）：
1. 入站数据包到达节点网卡
2. XDP（eXpress Data Path）eBPF 程序执行早期过滤
3. 数据包进入 TC（Traffic Control）eBPF 程序
4. 根据源/目的身份查找策略表
5. 策略决策：允许（ALLOW）或拒绝（DROP）
6. 如果允许，执行 VXLAN/Geneve 封装（Overlay 模式）或直接路由（Native Routing 模式）
7. 数据包转发到目标 Pod 的 veth 端点
8. 目标 Pod 的 eBPF 程序执行入站策略检查
9. 数据包交付给 Pod 内的应用程序- 零拷贝：eBPF 程序直接操作数据包，无需用户态与内核态切换。
- 动态更新：eBPF 程序可以在不重启进程、不中断连接的情况下热更新。
- 细粒度控制：支持 L3/L4/L7 策略，以及基于 DNS、HTTP 方法的过滤。