2. Cilium核心架构：eBPF数据面、Agent、Operator组件详解
Cilium 的架构设计围绕三个核心组件展开：eBPF 数据面、Cilium Agent 和 Cilium Operator。理解这三者的职责与协作关系，是进行网络性能调优与资源配额规划的前提。eBPF 数据面负责内核中的高速包处理，Agent 负责控制面逻辑与 API 交互，Operator 则管理集群级别的生命周期任务。
2.1 整体架构概览
下图展示了 Cilium 在 Kubernetes 集群中的核心组件布局及其交互关系。eBPF 数据面运行在 Linux 内核中，Agent 以 DaemonSet 形式运行在每个节点上，Operator 则以 Deployment 形式运行在控制平面。
架构要点：Agent 是每个节点上的“大脑”，负责将网络策略、服务定义翻译为 eBPF 程序；Operator 是集群级别的“管家”，处理无需每节点重复的任务；eBPF 数据面是“高速执行器”，在内核中完成包处理。
2.2 eBPF 数据面：内核中的高速网络引擎
eBPF（extended Berkeley Packet Filter）是 Cilium 的核心技术基石。Cilium 利用 eBPF 在内核中动态注入网络处理程序，实现高性能的数据包转发、负载均衡、安全策略执行和可观测性。
2.2.1 eBPF 数据面的关键能力
| 能力维度 | 实现机制 | 性能优势 |
|---|---|---|
| 网络转发 | 通过 TC（Traffic Control）或 XDP（eXpress Data Path）挂载 eBPF 程序 | 绕过 iptables，减少内核态与用户态切换，延迟降低 40%~60% |
| 负载均衡 | 使用 eBPF map 实现 Service 后端查找与 NAT | 无需 conntrack 回写，吞吐量提升 3~5 倍 |
| 网络策略 | 基于身份（Security Identity）的 L3/L4/L7 策略执行 | 策略匹配在 eBPF 中完成，无额外进程开销 |
| 可观测性 | 通过 eBPF 采集网络流、DNS、HTTP 等事件 | 零侵入采集，CPU 开销低于 5% |
2.2.2 eBPF 数据面工作流程
当数据包到达节点网卡时，eBPF 程序在内核中按以下路径处理：
- XDP 入口：在驱动层直接处理，适用于 DDoS 防护和高性能转发。
- TC 入口：在协议栈入口处处理，适用于复杂策略和隧道封装。
- eBPF map 查询：查找 Service 映射、策略规则、身份标识。
- 转发决策：根据查询结果执行转发、丢弃、重定向或封装。
- 可观测性事件：将元数据写入 perf_event 或 map，供 Agent 消费。
性能调优关注点：eBPF 数据面的性能瓶颈通常出现在 map 查询频率过高或程序复杂度超标。建议将 eBPF 程序复杂度控制在 BPF 验证器允许的 4096 条指令以内，并合理使用 map 预分配。
2.3 Cilium Agent：节点级控制面
Cilium Agent 是一个运行在每个 Kubernetes 节点上的守护进程（DaemonSet），它是 Cilium 的控制面核心。Agent 负责与 Kubernetes API Server 通信，监听资源变化，并将这些变化编译为 eBPF 程序和数据。
2.3.1 Agent 的核心职责
- CNI 插件实现：处理 Pod 的网络创建与删除，分配 IP 地址，配置网络接口。
- eBPF 程序管理：编译、加载、更新和卸载 eBPF 程序及 map。
- 服务与策略同步：监听 Service、Endpoint、NetworkPolicy、CiliumNetworkPolicy 等资源。
- 身份管理：为每个 Pod 分配安全身份（Security Identity），用于策略匹配。
- 可观测性数据聚合：从 eBPF 数据面收集流日志、指标，并通过 Prometheus 暴露。
- KVStore 交互：在集群模式下与 etcd 或 Kubernetes CRD 后端同步状态。
2.3.2 Agent 的资源消耗特征
| 资源类型 | 消耗特征 | 影响因素 |
|---|---|---|
| CPU | 中等，主要消耗在 eBPF 编译、策略计算、API 监听 | Pod 密度、策略复杂度、服务数量 |
| 内存 | 较高，eBPF map 和状态缓存占用主要内存 | Endpoint 数量、Identity 数量、流日志缓冲区 |
| 网络带宽 | 低，仅用于与 API Server 和 KVStore 通信 | 集群规模、资源变更频率 |
资源配额提示：在大型集群（>500 节点）中，Agent 的内存占用可能达到 1~2 GiB。建议为 Agent 设置 requests: 256m CPU / 512Mi 内存，limits: 1 CPU / 2Gi 内存，并根据实际监控数据调整。
2.4 Cilium Operator：集群级生命周期管理
Cilium Operator 是一个 Deployment 级别的组件，通常只运行一个副本（或两个用于高可用）。Operator 负责执行那些不需要在每个节点上重复执行的集群级任务。
2.4.1 Operator 的核心职责
- CRD 管理：确保 Cilium 所需的 CRD（如 CiliumNetworkPolicy、CiliumEndpoint）在集群中注册。
- 身份分配：为集群中的每个端点分配全局唯一的 Security Identity。
- 节点初始化：在新节点加入集群时，触发 Agent 的初始化流程。
- CiliumEndpoint 同步：维护 CiliumEndpoint 资源的状态，确保与 Agent 上报信息一致。
- 故障恢复：检测 Agent 失联或状态异常，触发重新调度或清理。
2.4.2 Operator 与 Agent 的职责对比
| 对比维度 | Cilium Agent | Cilium Operator |
|---|---|---|
| 部署模式 | DaemonSet（每节点一个） | Deployment（通常 1~2 副本） |
| 主要工作 | eBPF 管理、CNI、策略执行 | CRD 管理、身份分配、节点初始化 |
| API Server 交互频率 | 高（持续监听资源变更） | 低（仅在集群事件时触发） |
| 资源消耗 | 中到高（随节点 Pod 密度增长） | 低（通常 100m CPU / 256Mi 内存） |
| 故障影响范围 | 仅影响所在节点 | 影响全局身份分配和 CRD 管理 |
2.5 组件协作流程示例
以下是一个 Pod 创建过程中，三个核心组件的协作时序：
- kube-scheduler 将 Pod 调度到工作节点。
- kubelet 调用 Cilium CNI 插件（Agent 的一部分）创建网络接口。
- Agent 为 Pod 分配 IP 地址和安全身份，并加载对应的 eBPF 程序。
- Agent 将新的 Endpoint 信息上报给 Operator。
- Operator 更新 CiliumEndpoint CRD 状态，确保全局身份唯一性。
- Agent 将 eBPF map 中的转发规则同步到其他节点的数据面。
调优启示：在 Pod 频繁创建/销毁的场景下，Agent 的 eBPF 编译和 map 更新是主要性能瓶颈。建议启用 eBPF map 预分配，并调整
--bpf-map-dynamic-size-ratio 参数以适配工作负载。
2.6 组件资源配额建议
基于生产环境经验，下表给出了 Cilium 核心组件的 Helm 资源配额推荐值：
| 组件 | requests | limits | 适用场景 |
|---|---|---|---|
| Agent | 256m CPU / 512Mi 内存 | 1 CPU / 2Gi 内存 | 中小型集群（<100 节点） |
| Agent | 512m CPU / 1Gi 内存 | 2 CPU / 4Gi 内存 | 大型集群（100~500 节点） |
| Operator | 100m CPU / 128Mi 内存 | 500m CPU / 512Mi 内存 | 所有规模 |
| KVStore（etcd） | 200m CPU / 512Mi 内存 | 1 CPU / 2Gi 内存 | 集群模式专用 |
协同优化要点：Agent 的资源配额直接影响 eBPF 数据面的响应速度。当 Agent 因 CPU 限流导致 eBPF 编译延迟时，Pod 网络就绪时间会显著增加。建议将 Agent 的 CPU request 设置为与节点核心数成比例，例如每 10 个 Pod 分配 50m CPU。