1. Cilium 项目概述：起源、核心特性与云原生网络定位

1.1 起源：从容器网络到 eBPF 革命

Cilium 项目由 Thomas Graf 于 2016 年创立，最初是作为 Docker 容器的网络插件出现。其核心创新在于利用 Linux 内核的 eBPF（extended Berkeley Packet Filter）技术，替代传统的 iptables 和 overlay 网络方案。eBPF 允许在 Linux 内核中安全地运行沙箱化程序，而无需修改内核源码或加载内核模块。Cilium 正是借助这一能力，将网络、安全和可观测性逻辑直接注入内核数据路径，实现了前所未有的性能与灵活性。

1.2 核心特性：eBPF 驱动的三大支柱

Cilium 的能力体系围绕 eBPF 构建，主要涵盖网络、安全和可观测性三个维度。下表总结了其核心特性与对应技术实现：

1.3 云原生网络定位：CNI 的进化与差异化

在 Kubernetes 网络模型中，Cilium 作为 CNI（Container Network Interface）插件，承担 Pod 网络连通性的基础职责。但与传统 CNI（如 Calico、Flannel）不同，Cilium 的定位远不止于网络连通：

• 超越 CNI 边界： 提供内置的 Service Mesh（基于 Envoy 的 L7 代理）、Ingress/Gateway API 支持、多集群网络（Cluster Mesh）等高级功能。
• 安全原生集成： 网络策略（NetworkPolicy）直接由 eBPF 执行，无需 iptables 规则转换，支持 DNS、HTTP、gRPC 等 L7 协议感知。
• 可观测性即基础设施： Hubble 组件将网络流数据作为一等公民输出，与 Prometheus、Grafana、OpenTelemetry 生态无缝对接。

以下 SVG 图展示了 Cilium 在 Kubernetes 节点内的核心架构与数据流：

1.4 数据传输优化的核心优势

在数据传输优化场景中，Cilium 相比传统 CNI 方案具有以下关键优势：

1. 内核级数据路径加速： eBPF 程序直接挂载在网络设备（TC/BPF）和套接字（Socket BPF）上，数据包无需经过 iptables 规则链和用户态代理，延迟降低 50% 以上。
2. 无 sidecar 的 Service Mesh： 传统 Istio/Linkerd 需要在每个 Pod 中注入 sidecar 代理，导致额外的 5-15ms 延迟和 20-30% 的资源开销。Cilium 通过 eBPF 实现 L7 策略执行，完全消除 sidecar 开销。
3. 智能负载均衡： 基于 eBPF 的 Maglev 一致性哈希和 Maglev 负载均衡算法，支持连接级别的会话保持，避免传统 iptables 的随机转发导致的连接抖动。
4. 透明加密与零信任： 利用 WireGuard 或 IPsec 实现节点间加密，eBPF 在数据路径中自动加解密，对应用完全透明，无需修改代码或配置。

1.5 生态定位与未来演进

Cilium 已被纳入多个主流云原生发行版，包括：

• Google Kubernetes Engine (GKE) Dataplane V2： 默认使用 Cilium 作为网络插件。
• Amazon EKS Anywhere： 推荐 Cilium 作为网络方案。
• Red Hat OpenShift： 从 4.11 版本开始支持 Cilium 作为可选 CNI。
• Isovalent Enterprise： Cilium 的商业化发行版，提供企业级支持与附加功能。

未来发展方向包括：更深入的 eBPF 硬件卸载（SmartNIC/DPU）、多集群联邦网络（Cluster Mesh 增强）、以及将 eBPF 扩展到 Windows 节点支持。Cilium 正在从“CNI 插件”演变为“云原生网络基础设施平台”。

以下 SVG 图展示了 Cilium 在云原生生态中的定位与上下游关系：