2. Cilium基础回顾：Cilium架构组件、eBPF数据路径与CiliumEndpoint概念
在深入多租户控制面架构之前，必须重新校准对Cilium核心组件的理解。本章聚焦三个基础支柱：控制面组件（Agent & Operator）、数据面引擎（eBPF）以及关键抽象（CiliumEndpoint）。这些概念是后续所有策略配置工程的基石。
2.1 Cilium架构组件：Agent与Operator的分工
Cilium采用去中心化的控制面设计，每个Kubernetes节点上运行一个Cilium Agent，而集群范围内仅运行一个或少数几个Cilium Operator。这种分工决定了策略下发与状态管理的路径。
| 组件 | 部署模式 | 核心职责 | 与多租户的关系 |
|---|---|---|---|
| Cilium Agent | DaemonSet（每节点一个） | 管理本地eBPF程序、监听Kubernetes资源、维护本地Endpoint状态、执行网络策略 | 每个Agent独立处理本节点租户Pod的策略计算，是策略执行的最后一公里 |
| Cilium Operator | Deployment（通常2副本） | 处理集群级任务：IPAM分配、Service倒换、CiliumNetworkPolicy状态聚合、节点故障检测 | Operator不参与数据面转发，但负责多租户IP池的分配与回收 |
| CNI Plugin | 二进制插件（由kubelet调用） | 在Pod创建时调用Cilium Agent分配IP、配置网络命名空间、挂载eBPF程序 | CNI是租户Pod进入Cilium网络的第一道关口 |
关键理解： Agent是“本地策略执行者”，Operator是“集群状态协调者”。在多租户场景中，Agent负责实时计算租户隔离策略，Operator负责确保租户IP资源不冲突。
2.2 eBPF数据路径：从Pod到网络的完整链路
Cilium的数据面完全构建在eBPF之上，绕过了传统的iptables/IPVS路径。eBPF程序被挂载在网络栈的多个钩子点，实现高性能转发与策略执行。
性能优势： eBPF数据路径避免了内核态与用户态的频繁切换。Cilium Agent仅在策略变更时更新eBPF map，数据面转发完全在内核eBPF虚拟机中完成，延迟通常在微秒级。
2.3 CiliumEndpoint：身份与策略的绑定点
CiliumEndpoint（CEP）是Cilium中最重要的抽象之一。每个Kubernetes Pod在Cilium网络中都对应一个CEP资源，它记录了该Pod的网络身份（Security Identity）、IP地址、所属节点以及当前策略状态。
CEP是策略引擎进行决策的核心依据。当Cilium Agent收到一个数据包时，它通过查找源和目标CEP的身份标签，快速匹配对应的CiliumNetworkPolicy规则。
2.4 核心概念总结
| 概念 | 作用域 | 与多租户策略的关联 |
|---|---|---|
| Cilium Agent | 节点级 | 本地策略执行，负责本节点租户Pod的eBPF程序加载与更新 |
| Cilium Operator | 集群级 | 租户IP池管理、集群策略状态聚合 |
| eBPF数据路径 | 内核级 | 高性能策略匹配，支持L3/L4/L7的租户隔离 |
| CiliumEndpoint | Pod级 | 身份标签绑定，策略匹配的核心对象，支持动态迁移 |
常见误区： 不要将CiliumEndpoint与Kubernetes Endpoint混淆。Kubernetes Endpoint是Service的后端Pod IP列表，而CiliumEndpoint是Cilium内部用于策略决策的身份对象。在多租户场景中，CEP的身份标签是策略隔离的第一道防线。