2、Cilium架构基础：Cilium Agent、Cilium Operator、Cilium CNI插件、eBPF数据路径的核心组件
Cilium 的架构围绕 eBPF（extended Berkeley Packet Filter）构建，将数据平面与控制平面解耦。理解其核心组件是分析升级对租户隔离影响的前提。本章从 Cilium Agent、Cilium Operator、Cilium CNI 插件 和 eBPF 数据路径 四个维度展开。
2.1 整体架构概览
下图展示了 Cilium 在 Kubernetes 集群中的核心组件及其交互关系。Agent 运行在每个节点上，Operator 管理集群级资源，CNI 插件负责 Pod 网络接入，eBPF 程序则在内核中执行数据包处理。
2.2 Cilium Agent：节点级控制平面
Cilium Agent 以 DaemonSet 方式运行在每个 Kubernetes 工作节点上，是 Cilium 最核心的组件。它负责与 Kubernetes API Server 交互，监听 Pod、Service、NetworkPolicy 等资源变化，并将这些事件转化为 eBPF 程序加载到内核中。
2.2.1 Agent 的主要职责
| 职责领域 | 具体功能 | 对租户隔离的影响 |
|---|---|---|
| 身份管理 | 为每个 Pod 分配安全身份（Security Identity） | 身份是隔离策略的原子单位，升级期间身份分配逻辑变化可能导致策略误判 |
| 策略执行 | 将 CiliumNetworkPolicy 编译为 eBPF map 条目 | 策略编译规则变更可能影响租户间的流量放行或阻断 |
| eBPF 生命周期 | 加载、更新、卸载 eBPF 程序和 map | 升级过程中 eBPF 程序的热替换机制决定是否存在流量中断窗口 |
| 服务负载均衡 | 通过 eBPF 实现 kube-proxy 替代 | 负载均衡算法变更可能影响跨租户服务的连接一致性 |
| 监控与可观测性 | 通过 Hubble 暴露流量元数据 | 升级期间监控数据流中断会影响隔离违规的检测能力 |
2.2.2 Agent 的内部组件
Agent 内部由多个子模块协同工作，关键模块包括：
- Endpoint Manager：管理节点上所有 Pod 的端点状态，维护身份与网络命名空间的映射。
- Policy Repository：存储并编译网络策略，生成 eBPF map 的键值对。
- Datapath Regenerator：当策略或端点变化时，触发 eBPF 程序的增量更新。
- Node Discovery：通过 CRD 或 KV 存储发现集群节点拓扑。
2.3 Cilium Operator：集群级协调器
Cilium Operator 是集群级别的控制器，通常以 Deployment 方式运行（推荐 2 副本高可用）。它不直接参与数据路径，而是负责管理集群范围的资源分配和故障恢复。
2.3.1 Operator 的核心功能
| 功能 | 说明 | 与升级的关系 |
|---|---|---|
| 身份分配 | 为每个安全身份（Security Identity）分配全局唯一的数值 ID | 升级期间身份 ID 池的迁移策略影响存量 Pod 的身份连续性 |
| IPAM | 管理集群 IP 地址池（CRD-backed 或 ENI 模式） | IPAM 模式变更可能导致 Pod IP 冲突或分配失败 |
| KVStore 维护 | 当使用 etcd 作为后端时，负责与 etcd 交互 | KVStore 连接中断会导致 Agent 间状态同步失败 |
| 故障恢复 | 检测 Agent 失联并清理残留端点 | 升级过程中 Operator 的故障检测阈值影响隔离策略的收敛速度 |
2.3.2 Operator 与 Agent 的协作
Operator 通过 CRD（Custom Resource Definition）与 Agent 通信。典型的协作流程如下：
- Operator 监听 Kubernetes 事件，为新的 Pod 分配安全身份 ID。
- Operator 将身份 ID 写入
CiliumIdentityCRD。 - Agent 通过 Watch 机制感知到新的
CiliumIdentity，更新本地 eBPF map。 - 当 Pod 删除时，Operator 回收身份 ID 并清理 CRD。
2.4 Cilium CNI 插件：Pod 网络接入点
Cilium CNI 插件是一个轻量级二进制文件，由 kubelet 在创建 Pod 时调用。它负责将 Pod 的网络命名空间接入 Cilium 管理的数据路径。
2.4.1 CNI 插件的工作流程
- ADD 操作：kubelet 调用 CNI 插件，传入 Pod 的 network namespace 路径、容器 ID 和网络配置。
- 接口创建：CNI 插件创建 veth pair，一端放入 Pod 的 netns，另一端留在主机。
- IP 分配：CNI 插件通过 IPAM 模块（内置或外部）为 Pod 分配 IP 地址。
- 路由与策略：CNI 插件在主机端配置路由规则，并通知 Cilium Agent 加载对应的 eBPF 程序。
- 返回结果：CNI 插件将接口信息、IP、DNS 等返回给 kubelet。
2.4.2 CNI 插件的版本兼容性
CNI 插件与 Agent 是强耦合的。CNI 插件通过 Unix Socket 或 gRPC 与本地 Agent 通信。升级时，CNI 插件的二进制文件必须与 Agent 版本匹配。
| 场景 | 影响 | 建议 |
|---|---|---|
| CNI 插件版本 < Agent 版本 | CNI 插件可能无法正确调用新 Agent 的 API，导致 Pod 创建失败 | 优先升级 CNI 插件二进制 |
| CNI 插件版本 > Agent 版本 | CNI 插件可能请求新 Agent 才支持的功能，导致回退或错误 | 确保 Agent 先升级 |
| CNI 配置变更 | 升级可能修改 cni-config 中的 chaining 模式或 IPAM 类型 |
升级前备份配置，验证新配置兼容性 |
2.5 eBPF 数据路径：内核中的执行引擎
eBPF 数据路径是 Cilium 实现高性能网络和隔离的核心。Cilium 在多个内核 hook 点注入 eBPF 程序，形成完整的数据处理流水线。
2.5.1 数据路径的层次结构
下图展示了从 Pod 出站到对端 Pod 入站的完整 eBPF 数据路径，以及各层负责的隔离检查点。
2.5.2 关键 eBPF 程序类型
| 程序类型 | 挂载点 | 功能 | 隔离相关 |
|---|---|---|---|
| XDP | 网卡驱动层 | 最早期的包处理，用于 DDoS 防护和转发 | 可基于源 IP 做粗粒度隔离 |
| TC Ingress | 协议栈入口 | 出站流量处理，附加身份标签 | 检查出站策略，决定是否放行 |
| TC Egress | 协议栈出口 | 入站流量处理，执行入站策略 | 检查入站策略，决定是否放行 |
| L7 Proxy | 用户态代理（Envoy） | HTTP/gRPC/Kafka 等七层协议解析 | 执行七层隔离策略（如 HTTP 方法、路径） |
2.5.3 eBPF Map：隔离策略的存储核心
eBPF 程序不直接存储策略，而是通过 eBPF Map 与用户态的 Cilium Agent 共享数据。关键的 Map 包括：
- Policy Map：存储身份到身份的允许规则，键为
(源身份, 目标身份, 端口)。 - Endpoint Map：存储节点上所有 Pod 的 IP 与身份映射。
- CT Map：连接跟踪表，记录已建立的连接状态，用于有状态策略。
2.6 组件依赖关系总结
下表总结了四个核心组件之间的依赖关系，以及升级时需要注意的耦合点：
| 组件 | 依赖上游 | 依赖下游 | 升级耦合度 |
|---|---|---|---|
| Cilium Agent | Kubernetes API Server、Cilium Operator | eBPF 内核子系统、CNI 插件 | 高（与 CNI 插件和 eBPF 版本强绑定） |
| Cilium Operator | Kubernetes API Server | Cilium Agent（通过 CRD） | 中（CRD 版本兼容性） |
| Cilium CNI 插件 | Cilium Agent（通过 gRPC） | kubelet | 高（二进制版本必须匹配 Agent） |
| eBPF 数据路径 | Cilium Agent（加载程序） | Linux 内核（eBPF 运行时） | 高（内核版本决定 eBPF 特性集） |