Cilium 架构基础：核心组件与 eBPF 原理
Cilium 是一个基于 eBPF（extended Berkeley Packet Filter）的云原生网络、安全和可观测性解决方案。理解其架构是进行 Helm 资源配额与性能调优的前提。本章将深入解析 Cilium 的核心组件、eBPF 技术原理以及数据路径转发模型。
2.1 Cilium 核心组件详解
Cilium 的架构由多个协同工作的组件构成，每个组件在数据平面和控制平面中扮演特定角色。下表总结了主要组件的功能与部署形态：
| 组件名称 | 部署类型 | 核心职责 | 资源敏感度 |
|---|---|---|---|
| Cilium Agent | DaemonSet（每节点一个） | 管理 eBPF 程序、实现网络策略、服务负载均衡、监控端点 | 高（CPU/内存直接影响转发性能） |
| Cilium Operator | Deployment（通常 1-2 副本） | 处理集群级任务：CRD 同步、身份管理、节点间协调 | 中（主要影响控制面响应速度） |
| CNI 插件 | 二进制文件（由 kubelet 调用） | 将 Pod 接入 Cilium 网络，分配 IP 并配置网络接口 | 低（仅 Pod 创建时触发） |
| CRD 控制器 | 内嵌于 Agent/Operator | 监听 CiliumNetworkPolicy、CiliumEndpoint 等自定义资源 | 中（CRD 数量多时影响 API Server 负载） |
2.1.1 Cilium Agent
Agent 是 Cilium 最核心的组件，以 DaemonSet 方式运行在每个 Kubernetes 节点上。它负责将用户意图（网络策略、服务定义）编译为高效的 eBPF 程序，并加载到内核中。Agent 通过 gRPC 与 kube-apiserver 通信，监听 Pod、Service、Endpoint 等资源变化，实时更新数据平面。
requests.cpu: 100m，limits.memory: 512Mi），并开启 cgroup.automount 以优化 eBPF 资源隔离。
2.1.2 Cilium Operator
Operator 负责集群级别的控制面逻辑，包括：
- CRD 管理： 确保 CiliumNetworkPolicy、CiliumEndpoint 等 CRD 在集群中注册并保持同步。
- 身份管理： 为每个安全标识（Security Identity）分配唯一 ID，并下发到各节点 Agent。
- 节点间协调： 处理跨节点的隧道或路由配置更新。
Operator 通常只需 1-2 个副本，资源需求较低，但高可用场景下建议配置 podAntiAffinity 避免单点故障。
2.1.3 CNI 插件与 CRD
CNI 插件是一个轻量级二进制文件，由 kubelet 在创建 Pod 时调用。它负责将 Pod 的网络命名空间接入 Cilium 管理的网络，并调用 Agent 的 API 完成 IP 分配和接口配置。CRD（Custom Resource Definition）是 Cilium 扩展 Kubernetes API 的方式，常用的 CRD 包括：
- CiliumNetworkPolicy： 定义基于 L3/L4/L7 的网络策略。
- CiliumEndpoint： 记录每个 Pod 的网络状态和安全标识。
- CiliumClusterwideNetworkPolicy： 集群范围的网络策略。
2.2 eBPF 核心技术原理
eBPF 是 Cilium 的技术基石。它允许用户在 Linux 内核中安全地运行沙箱化程序，而无需修改内核源码或加载内核模块。Cilium 利用 eBPF 实现数据包处理、策略执行和可观测性。
- 安全： 程序必须通过验证器（Verifier）检查，确保不会导致内核崩溃或死循环。
- 高效： 程序直接在内核态运行，避免上下文切换和用户态拷贝。
- 可编程： 支持在多个内核钩子点（如 XDP、TC、Socket）注入自定义逻辑。
Cilium 主要使用以下 eBPF 程序类型：
| eBPF 程序类型 | 挂载点 | 在 Cilium 中的用途 |
|---|---|---|
| XDP | 网卡驱动层（最早） | 高性能 DDoS 防护、早期包过滤、负载均衡 |
| TC（Traffic Control） | 内核协议栈入口/出口 | Pod 网络策略执行、封装/解封装（VXLAN/Geneve） |
| Socket BPF | Socket 层 | 服务网格（L7 策略）、HTTP/gRPC 协议感知 |
| Kprobe/Uprobe | 内核/用户函数 | 可观测性（如跟踪系统调用、DNS 请求） |
2.3 数据路径转发模型
Cilium 支持多种数据路径转发模型，每种模型在性能、兼容性和功能上有所取舍。选择正确的模型是性能调优的关键步骤。
2.3.1 隧道模式（Tunneling）
默认模式，使用 VXLAN 或 Geneve 封装。每个 Pod 的数据包在源节点被封装，在目标节点解封装。此模式对底层网络要求低，无需修改路由表，适合混合云和多网络环境。
- 优点： 网络兼容性好，无需配置底层路由；支持跨子网通信。
- 缺点： 封装/解封装带来额外 CPU 开销，MTU 需减少（通常为 1450）。
2.3.2 原生路由模式（Native Routing）
直接利用 Linux 内核路由表转发 Pod 流量，无需封装。Cilium 通过 eBPF 程序将 Pod IP 路由到正确的节点，依赖底层网络（如 BGP、云厂商路由表）完成跨节点转发。
- 优点： 性能更高（减少封装开销），MTU 无需缩减。
- 缺点： 需要底层网络支持路由分发（如 BGP 或云厂商 VPC 路由表），配置复杂度高。
2.3.3 直接路由模式（Direct Routing）
类似原生路由，但 Cilium 不修改内核路由表，而是通过 eBPF 在 TC 层直接重定向数据包到目标节点的 MAC 地址。此模式通常与 kube-proxy 替换结合使用。
tunnel: disabled 或 routingMode: native 切换。