K8s网络插件还在用 Calico、Flannel?Cilium 凭什么成为 K8s 网络首选

在很多 Kubernetes 团队里，网络插件长期是个 “低存在感” 的基础组件。装个Flannel 或者Calico，只要Pod 跨节点能通、Service能访问、NetworkPolicy能做基础隔离，似乎就完成了任务。业务关注发版扩缩，运维关注节点状态，没人会特意深究CNI 本身。

但当云原生走到深水区，这套 “凑合用” 的逻辑很快就走不通了。微服务越拆越多，东西向流量指数级增长；Service Mesh、网关、代理层层叠加，调用链越拉越长；安全要求从边界防护下沉到工作负载级别；排障也从 “看 Pod 是不是 Running”，变成要追踪一次请求在 IP、端口、DNS、策略、应用协议之间的完整路径。

传统 CNI 的短板，在这个阶段集中爆发：iptables 规则越堆越多，Service 转发性能和稳定性下降；网络策略停留在 L3/L4，管不住 HTTP、gRPC 这类应用层访问；排查问题要在多个工具间反复横跳，链路完全割裂。集群规模越大，这些问题越棘手。

而 Cilium 的出现，正是对这些痛点的一次系统性重构。它不是又一个普通 CNI 插件，而是基于 eBPF 把 K8s 的网络转发、安全策略、流量观测全部下沉到内核可编程数据路径，把K8s 网络从 “规则堆叠时代” 带进了 “内核可编程数据面时代”。

一、传统K8s网络的四个核心瓶颈

Kubernetes 的网络模型本身很简单：Pod 独立 IP、默认互通、Service 做稳定入口、CNI 负责底层连通。小规模集群里，不管是 Flannel 的覆盖网络，还是 Calico 的 BGP+iptables 方案，都足够用。但规模和复杂度上来之后，四个问题会越来越突出。

Service转发的性能瓶颈。传统kube-proxy 靠iptables 或IPVS 实现Service 负载均衡。iptables本质是规则逐条匹配，Service和Endpoint 越多，规则集越庞大。尤其在Pod 高频扩缩容、滚动发布的场景下，规则同步延迟、瞬时不一致带来的访问抖动，会变成很隐蔽的生产隐患。IPVS虽然性能更好，但在可观测性、策略融合上依然和数据面脱节。

网络策略的表达力不足。标准NetworkPolicy 只能管到L3/L4，也就是 “谁的 IP 能访问哪个端口”。但企业真实的安全需求，往往是 “能访问哪个 API、用什么 HTTP 方法、能不能碰敏感路径”。端口一开，所有接口全放开，根本做不到细粒度的服务间隔离。

可观测性严重割裂。应用报502、超时、连接拒绝，运维要逐层查DNS、查Endpoint、查iptables、查策略、查Ingress、查应用日志。每个环节的信息在不同工具里，没有统一的流量视角，定位一个网络问题常常要耗掉大半天。

性能与安全越叠越重。要观测就加Sidecar，要安全就加策略引擎，要审计再加日志采集。每叠一层就多一份资源开销，多一个故障点。这些能力都是后期拼装上去的，不是原生融合，最后整个网络栈又重又难维护。

二、eBPF到底改写了什么？

理解 Cilium，绕不开 eBPF，但不用把它想得太玄乎。简单说，eBPF可以把一段经过安全校验的程序，加载到Linux 内核的关键路径上，比如网络包收发、系统调用、socket处理的位置。它不用修改内核源码，不用加载高风险内核模块，却能在内核态直接高性能地处理数据包、连接和进程行为。

对应到 K8s 网络里，过去要靠用户态进程、靠大量静态规则做的事，现在可以直接在内核数据路径里完成。传统iptables 的逻辑是 “提前生成成千上万条规则，数据包过来逐条匹配”；eBPF 的逻辑是 “把决策逻辑编译成程序，挂在必经路径上，数据包过来直接执行”。小规模下两者差异不大，但当规则数量爆炸、服务频繁变更、策略越来越复杂，eBPF的优势就会被彻底拉开。

Cilium 正是把 eBPF 的能力用到了极致：替代 kube-proxy 做内核级 Service 负载均衡、基于工作负载身份做策略、支持 L7 协议管控、为可观测性提供原生流量数据，还能延伸出透明加密、多集群通信等能力。它的核心不只是 “更快”，而是让 K8s 数据面第一次具备了可编程、可感知、可原生扩展的能力。

三、Cilium的核心优势：网络、安全、观测三合一

很多人初识 Cilium 只把它当 CNI，真正用起来才会发现，它的能力边界早就超出了 “让 Pod 通网” 的范畴。网络、安全、可观测性三套能力共享同一条数据路径、同一套身份体系、同一种 K8s 语义，这是传统方案拼不出来的效果。

在网络层面，它重构了数据转发效率。Cilium 可以完整替代kube-proxy，在内核中直接完成Service 负载均衡，大幅减少iptables 规则依赖。除此之外，Pod跨节点通信、Overlay / 原生路由、BGP集成、Egress网关、多集群Cluster Mesh，从单集群基础网络到多集群服务互通，它都能完整覆盖。很多人听过“Cilium 性能提升30%-50%” 的说法，其实更准确的表述是：在大规模Service、高频Endpoint 变更、东西向流量密集的场景下，它的收益非常明显；而小规模集群的核心价值，更多体现在规则复杂度降低、排障效率提升和后续扩展能力上。
在安全层面，它把策略从 IP 升级到了身份。这是Cilium 最贴合K8s 本质的设计。Pod的IP 随时会变，但它的命名空间、标签、ServiceAccount这些身份属性是稳定的。Cilium的策略围绕身份构建，而不是围绕易变的IP。除了兼容标准K8s NetworkPolicy，它还支持更强大的CiliumNetworkPolicy，能管控DNS 域名、HTTP方法与路径、Kafka Topic 等L7 维度。比如限制报表服务只能调用用户服务的GET /profile 接口，而不能碰管理接口—— 这在传统L4 策略里根本做不到。对零信任架构来说，这种 “工作负载级最小权限” 的控制，比单纯放开端口有价值得多。
在可观测层面，它让网络排障从猜测变成可解释。配套的Hubble 组件，直接从Cilium 数据面提取流量事件，能展示服务依赖拓扑、流量方向、源目身份、协议信息、策略判定结果、HTTP状态码、DNS查询结果。以前排查 “服务 A 访问服务 B 为什么失败”，要翻好几个工具；现在用 Hubble 一眼就能看到：是被策略拒绝了，还是 DNS 解析失败，还是后端无响应，甚至能看到具体是哪条策略命中了拒绝。除此之外，它还能基于真实流量生成服务地图，帮团队发现文档里没写的隐式依赖、无效调用，为架构治理和策略收敛提供依据。

这三者结合起来的价值，远大于单点工具。网络负责连通，安全负责边界，观测负责解释，三者同源，避免了重复建设和数据割裂。

四、和Calico、Flannel比，该怎么选？

选型从来不是 “谁更好”，而是 “谁更适合当下的场景”。

Flannel 的优势是极致简单，学习成本极低，只解决 Pod 跨节点通信。适合测试环境、小型集群，对安全和观测没太高要求的场景。但要做精细化治理，就必须叠加其他组件。
Calico 成熟稳定，生态完善，尤其在 BGP 路由、L3/L4 网络策略上有大量生产实践。如果你的需求集中在基础路由和端口级策略，现有集群运行稳定，那 Calico 依然是非常可靠的选择。
Cilium 的优势是 eBPF 数据面、身份化策略、L7 管控、Hubble 观测、kube-proxy 替代，走的是网络安全观测一体化的路线。它更适合规模化生产集群，适合正在推进零信任、被排障和 iptables 问题困扰、未来有多集群规划的团队。

简单说：小环境求简选 Flannel，传统稳定生产选 Calico，要现代化数据面和一体化治理选 Cilium。不用盲目追热度，匹配自己的阶段最重要。

五、落地Cilium，最稳妥的路径是什么？

Cilium 能力很强，但生产落地绝不能上来就全量开启所有功能。更稳妥的方式是分阶段推进。

验证基础连通性先在测试集群或新建非核心集群部署，验证Pod 通信、Service访问、DNS、Ingress、存储监控等基础能力，重点确认兼容性，不要急于上高级功能。
先上 Hubble 可观测性让团队先熟悉Hubble 的UI 和CLI，用真实流量跑通排障流程。这一步投入产出比最高，哪怕暂时不改网络策略，也能立刻解决排障难的问题。
迁移基础网络策略先从命名空间隔离、环境隔离、核心服务防护这类L3/L4 规则开始，配合Hubble 观察流量，确认无误伤再逐步收敛，不要一上来就写复杂L7 策略。
评估 kube-proxy 替代选择流量模型清晰的集群做压测和灰度，重点验证延迟、吞吐、CPU开销、NodePort/LoadBalancer兼容性，确认稳定后再推广到核心集群。
按需启用高级能力L7 策略、DNS策略、Egress网关、透明加密、多集群这些能力，要围绕具体业务需求启用。比如高风险服务做L7 接口管控，多地域集群做Cluster Mesh，没有明确需求不要过早引入。

迁移前还有几个必须评估的关键点：Linux 内核版本（eBPF 能力和内核强相关，尽量选用官方推荐的版本范围）、存量策略的语义差异、kube-proxy 替代的兼容性、观测数据的存储成本，以及完整的回滚方案。毕竟CNI 是集群底座，一旦出问题影响面极大。

六、最后总结下

Cilium 不是能解决所有问题的银弹。它带来了 eBPF、身份策略、Hubble 这些新概念，也对团队的平台工程能力提出了更高要求。但有一个趋势是确定的：当Kubernetes 从 “能跑应用” 进入 “规模化治理” 的阶段，传统靠零散组件拼接出来的网络、安全、观测体系，维护成本会越来越高。

Cilium 的价值，正是把这些能力整合到了同一条云原生数据面里：用 eBPF 实现高性能可编程，用身份模型匹配 K8s 的动态本质，用 Hubble 让流量变得可解释。它回应的不只是网络性能问题，更是整个云原生平台的治理需求。

对于正在建设新一代 K8s 平台的团队，Cilium 完全值得作为默认候选；对于已有存量集群的团队，也可以先从测试环境、可观测性和局部策略治理开始验证。技术选型的核心从来不是追新，而是用对的工具，解决真实的治理痛点。