Cilium：用 eBPF 重写 Kubernetes 网络、安全与可观测性的底层逻辑
基于 eBPF 的网络、安全性和可观察性
秒懂
- 它是什么？
- Cilium 是一个基于 eBPF 数据面的网络、安全与可观测性方案，定位为 kube-proxy 的替代者。它用身份而非 IP 地址做安全模型，值得认真评估，但内核版本和运维复杂度是绕不开的门槛。
- 适合谁用？
- 如果你的 Kubernetes 集群规模大、策略复杂，或者你正被 kube-proxy 的性能和 iptables 规则数量困扰，Cilium 值得认真评估。它用 eBPF 哈希表替代 iptables 链，把安全模型从 IP 地址解耦到身份，这在大规模多租户场景下有真实优势。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是 kube-proxy 和 IP 地址绑定的老问题
传统 Kubernetes 网络依赖 iptables 做服务转发，规则数量随服务和端点增长而膨胀，大规模集群里更新一条规则可能耗时数秒。Cilium 用 eBPF 哈希表替代这条链路，README 明确说它可以完全替换 kube-proxy，并声称支持几乎无限的规模扩展。另一个痛点是安全策略，传统 NetworkPolicy 基于 IP 地址，Pod 重启或扩缩容后地址变化，策略就得跟着改。Cilium 把安全模型从地址解耦到身份，Pod 的标签决定它的身份，策略跟着身份走，地址变了策略不用动。这个设计的受众很明确：运行大规模 Kubernetes、对网络延迟敏感、或者安全策略复杂到难以用 IP 维护的团队。
eBPF 数据面：字节码注入内核，而不是用户态转发
Cilium 的根基是 eBPF，一种允许在 Linux 内核的多个挂载点动态插入字节码的技术。网络 IO、应用 socket、tracepoint 都是它的注入位置。这意味着数据包处理发生在内核态，不需要把包拷贝到用户态再转发，省掉了一次上下文切换。Cilium 在 eBPF 里用高效的哈希表实现分布式负载均衡，这是它能替代 kube-proxy 的机制基础。数据流上，Pod 发出的包经过 veth 进入主机，eBPF 程序在 tc 或 XDP 挂载点接管，根据目标身份和服务映射直接转发。这个架构的好处是路径短，坏处是排障时你面对的是内核里的字节码，而不是熟悉的 iptables 规则或用户态代理日志。
CNI 的两种部署模式：overlay 和 native routing
作为 CNI 插件，Cilium 支持两种数据路径。Overlay 模式用 VXLAN 或 Geneve 封装，在主机之间建立虚拟网络，唯一要求是主机间有 IP 连通性，这几乎在任何基础设施上都满足，所以它是最省事的起点。Native routing 模式直接使用 Linux 主机的路由表，应用容器的 IP 必须能被底层网络路由，这要求你与云厂商路由器、BGP 守护进程或 IPv6 原生基础设施集成。README 还提到灵活的选路选项，比如节点共享二层域时用 L2 邻居发现，跨三层时用 BGP。选择哪种模式取决于你的网络现状，如果底层网络已经能路由 Pod IP，native routing 省掉封装开销；如果网络不可控，overlay 是安全选择。
身份安全模型：L3 到 L7 的策略，不依赖 IP 地址
Cilium 的安全模型核心是身份，而不是地址。每个 Pod 根据其标签获得一个身份标识，网络策略在 L3 到 L7 层基于这个身份执行。这意味着你可以在 L7 层限制某个身份只能访问特定 HTTP 路径或方法，而不只是开放端口。这种能力来自 eBPF 在 socket 层的挂钩，它能解析应用层协议。对多租户集群来说，这个模型解决了地址漂移问题，Pod 重启后身份不变，策略依然生效。但代价是，你要理解身份的生命周期，标签变更会触发身份重新计算和策略重载，这个过程的延迟和一致性需要在实际环境中验证。
不只是 CNI：ingress、egress 网关和服务网格
README 显示 Cilium 的边界比纯 CNI 宽得多。它实现了集成的 ingress 和 egress 网关，意味着你不需要单独部署 ingress controller 就能做南北向流量管理。带宽管理功能也在其中，可以给 Pod 设置带宽限制。服务网格功能是另一个大块，它不依赖 sidecar 代理，而是用 eBPF 在数据面直接处理服务间流量。这个设计减少了每个 Pod 的额外资源开销，但服务网格的流量管理、熔断、重试这些逻辑在 eBPF 里实现，调试复杂度比 Envoy 这类用户态代理高。你要评估的是，一体化的收益是否抵得过排障时的难度。
获取与运行：镜像、架构和版本节奏
Cilium 镜像发布在 quay.io/cilium/cilium，支持 AMD64 和 AArch64。当前稳定分支是 v1.20、v1.19 和 v1.18，社区只维护最近三个 minor 版本，更早的视为 EOL。这意味着升级是持续义务，不是一次性工作。从 v1.13.0 开始，所有镜像包含 SPDX 格式的软件物料清单（SBOM），这对合规审查有帮助。开发版本有 daily 构建的 cilium-ci 镜像和预发布分支，README 明确警告这些不能用于生产。如果你要做升级测试，需要查阅 Cilium Upgrade Guide，这个文档是官方指定的升级路径参考。
限制与替代方案：eBPF 不是万能药
Cilium 的局限首先在内核依赖。eBPF 功能随内核版本演进，老内核不支持新特性，你必须在集群所有节点上保证内核版本一致且足够新。其次是排障难度，数据面逻辑在内核字节码里，传统的 tcpdump 和 netstat 视角不够，你需要熟悉 bpftool 和 Cilium 自带的监控工具。替代方案方面，Calico 是直接对手，它也用 eBPF 数据面，但同样支持传统的 iptables 模式，迁移路径更平滑。Flannel 则简单得多，只做 overlay 网络，没有安全和可观测性功能，适合不需要复杂策略的小集群。Cilium 的取舍是功能密度高，但每项功能都要求你接受 eBPF 的排障成本。
维护成本与许可证：Apache-2.0 下的持续升级义务
许可证是 Apache-2.0，商用没有障碍，这点没有争议。真正的成本在维护节奏，三个活跃 minor 分支意味着你每年至少要跟进两个大版本。每次升级要读 Upgrade Guide，因为 eBPF 程序、配置项和默认行为都可能变化。SBOM 从 1.13.0 开始内置，这降低了供应链审计的难度，但不能减少升级本身的工作量。如果你的团队没有专门的人盯 Cilium 的 release notes，版本滞后会很快让你掉出支持窗口。这个项目的维护不是安装完就结束，它是一个需要持续投入的运行时组件。
编辑结论
如果你的 Kubernetes 集群规模大、策略复杂，或者你正被 kube-proxy 的性能和 iptables 规则数量困扰，Cilium 值得认真评估。它用 eBPF 哈希表替代 iptables 链，把安全模型从 IP 地址解耦到身份，这在大规模多租户场景下有真实优势。但如果你运行在老旧内核上，或者团队没有 eBPF 排障经验，它带来的复杂度可能超过收益。也不要忽略升级节奏，社区只维护最近三个 minor 版本，v1.18 之前的版本已 EOL，这意味着你每 6 到 9 个月就要规划一次大版本升级。决定采用前，先确认你的内核版本满足 eBPF 要求，用 kind 或 minikube 跑一遍 Cilium CLI 的 connectivity test，再决定是否值得把核心网络层交给它。
社区笔记