为什么Cilium是比Istio更好的选择 — 用eBPF统一网络和服务网格

结论是，Cilium并非总是优于Istio。然而，对于希望将Kubernetes网络、安全策略、负载均衡、可观测性和服务网格整合到一个平台的组织来说，Cilium可能是一个更简单、更一致的选择。

在评估服务网格时，我们经常会遇到一个问题：“我应该选择Istio还是Cilium？”

这个问题首先需要一个前提。Istio和Cilium的起点不同。Istio最初是作为控制服务间通信的服务网格而诞生的，而Cilium则以eBPF驱动的Kubernetes CNI和网络安全平台起步，并扩展到了服务网格领域。

因此，两者并非完全相同的产品。Istio是运行在CNI之上的服务网格，而Cilium本身就是CNI，同时还能提供网络策略、kube-proxy替代、可观测性以及L7代理功能。

尽管如此，在特定环境下，Cilium会是更好的选择。尤其是在以Kubernetes为中心的基础设施中，如果已经将Cilium用作CNI，并且大部分流量通过L3·L4策略就足够，只需要在必要区域应用L7功能时。

本文并非主张“Cilium无条件优于Istio”。其目的是区分在何种条件下Cilium的集成结构能带来实际优势，以及在何种条件下Istio仍然更适用。

首先要明确：Cilium和Istio有何不同

两款产品最大的区别在于其职责范围。

WRIMO-MD-TABLE-0]Cilium官方文档解释说，IP、TCP和UDP等网络处理在eBPF数据路径中执行，而HTTP、Kafka、gRPC和DNS等应用协议则由Envoy等代理进行解释。这意味着Cilium服务网格并非“完全不使用代理的网格”。 [Cilium Service Mesh 官方文档

Istio目前提供两种数据平面模式。传统的sidecar模式将Envoy放置在每个Pod旁边，而ambient模式则将功能分为节点级的L4代理ztunnel和按需使用的命名空间级L7 waypoint代理。 Istio 数据平面模式官方文档

理解这一区别有助于避免“没有sidecar所以Cilium一定更轻量”或“使用eBPF所以L7也全部在内核中处理”等夸大之词。

原因1：CNI和服务网格可以整合到一个平台

Cilium最实际的优势在于其集成性，而非单纯的数据包处理性能。

在典型的Kubernetes环境中，组合不同的产品可能会产生以下组件：

CNI插件
kube-proxy
Kubernetes NetworkPolicy 实现
服务网格
Ingress 或 Gateway API 控制器
网络流观测工具

Cilium可以在一个平台中承担其中多个角色。CNI和网络策略是基础，它还可以同时运行基于eBPF的kube-proxy替代、Gateway API、Hubble可观测性以及可选的L7代理。

Cilium的kube-proxy替代模式通过eBPF实现ClusterIP、NodePort、LoadBalancer和externalIPs服务处理。 Cilium kube-proxy replacement 官方文档

这种集成带来的好处并非简单地“进程数量一定会减少”。它意味着在分析故障时，追踪CNI、服务NAT、网络策略和服务网格在多个产品之间的边界的负担会减轻。

特别是如果平台团队负责整个Kubernetes网络，那么数据路径、策略模型和观测工具能够在一个产品系列中连接起来，将是运营上的巨大优势。

原因2：并非所有流量都需要L7代理

引入服务网格并不意味着所有通信都需要基于HTTP头的路由、重试和分布式追踪。

数据库连接、内部TCP协议、简单的服务发现以及与多个后端的通信，可能仅通过L3·L4安全策略和负载均衡就足够了。如果这类流量也让每个Pod都通过L7代理，那么代理数量、配置部署目标和资源预留量将随着应用副本数量的增加而增加。

Cilium通过eBPF处理L3·L4路径，并将仅需要L7解释的流量（如HTTP策略或Gateway API）发送到节点本地的Envoy。Cilium的L7策略通过节点本地的Envoy实例，Envoy可以在Cilium agent内部运行，也可以作为独立的DaemonSet运行。 Cilium Envoy 官方文档, Cilium L7 Policy 官方文档

这种结构在以下条件下具有优势：

服务数量和Pod副本数量众多。
大部分通信通过L4策略就足够。
仅部分API和外部入口点需要L7功能。
希望减少应用Pod的sidecar注入和重启。

然而，当比较对象是Istio sidecar时，优势最为显著。Istio ambient也消除了每个Pod的sidecar，通过节点级的ztunnel和可选的waypoint来分离L4和L7。Istio官方文档也解释说，ambient旨在减少sidecar方式的资源成本和运营负担。 Istio ambient 概述

因此，2026年的正确比较不应止于“Cilium 对比 Istio sidecar”。而应是“Cilium的eBPF+节点Envoy结构与Istio ambient的ztunnel+waypoint结构，哪一个更适合我们的组织？”

原因3：网络策略和可观测性源自相同的数据

在Kubernetes网络故障中，最难回答的问题很简单：

这个请求从哪里到哪里，是否被允许，如果被拒绝，是由于什么策略？

Cilium的Hubble使用从Cilium和eBPF数据路径观测到的流。它可以在节点、集群和ClusterMesh范围内检查服务间的流，Hubble UI不仅提供L3·L4，在满足条件时也提供L7服务图。 Hubble 官方文档

这种集成的好处是，安全策略和观测结果并非来自不同的收集层。

哪个Cilium安全身份进行了通信？
使用了哪个端口和协议？
是否被策略转发或拒绝？
在DNS或HTTP层面发生了哪些流？
哪个节点和工作负载出现了问题？

这些信息可以在同一个操作工具中关联起来。

Istio也提供了丰富的指标、分布式追踪和访问日志。它在分析应用层面的延迟、错误率和调用关系方面尤其强大。 Istio Observability 官方文档

区别在于观测的起点。Istio的中心是代理看到的服务请求，而Hubble的中心是CNI和eBPF数据路径看到的网络·安全流。对于网络策略调试至关重要的平台团队来说，Hubble的方法可能更直接。

原因4：可以围绕Kubernetes Gateway API调整运营模型

旧的Kubernetes基础设施为每个产品使用不同的Ingress注解和专用CRD。结果是，即使是相同的HTTP路由，更换平台也需要重新编写配置。

Cilium将Kubernetes Gateway API与数据平面连接起来。目前的稳定文档明确指出，它支持Gateway API v1.4.1的GatewayClass、Gateway、HTTPRoute、GRPCRoute和ReferenceGrant等，并已通过Core conformance test。 Cilium Gateway API 官方文档

如果平台团队将Gateway API作为标准入口点，可以将以下领域整理成接近统一的策略语言：

外部Ingress
服务间HTTP路由
gRPC路由
流量分割
头部修改
TLS终止

当然，Istio也积极使用Gateway API和ambient waypoint。因此，仅凭Gateway API支持本身并不能宣告Cilium的胜利。

Cilium更优的情况是，如果已经将Cilium用作CNI和负载均衡器，并希望在同一平台中继续使用Gateway API。这是因为它可以扩展现有的网络运营模型，而不是添加新的网格专用API和单独的数据平面。

原因5：平台团队可以减少需要管理的边界

在Istio sidecar环境中，应用程序部署和代理生命周期紧密耦合。sidecar注入设置的更改可能需要Pod重启，每个工作负载的CPU和内存请求量必须反映代理，并且应用程序问题和Envoy问题需要一并考虑。

Cilium的L7 Envoy可以作为节点级共享组件运行。由于每个应用程序副本不附加代理容器，因此更容易将平台组件的生命周期与应用程序Pod分离。

然而，共享代理也存在反向的权衡：

节点代理故障的影响范围可能扩大。
多个工作负载的L7流量可能竞争相同的代理资源。
需要进行节点级容量规划和故障隔离。
L7流量最终会支付Envoy的处理成本。

因此，更准确的理解不是“没有sidecar所以成本为0”，而是“成本和运营单位从按Pod转移到按节点”。

Istio ambient也类似地将代理生命周期管理转移到平台团队。官方比较文档解释说，在ambient模式下将工作负载添加到网格时不需要Pod重启，并且waypoint可以像普通的Kubernetes Deployment一样进行扩展。 Istio sidecar与ambient比较

最终，Cilium真正的优势并非仅仅是“没有sidecar”，而是在一个包含CNI和网络策略的单一平台中，能够运营无sidecar的架构。

那么，Istio在何时是更好的选择？

要正确阐述Cilium的优势，也必须明确Istio更优的条件。

1. 当成熟的mTLS和服务身份是首要任务时

Istio长期以来一直将标准mTLS、认证和授权作为服务网格的核心功能来运营。其主要目标是在包含Kubernetes外部VM、多个集群和不同CNI的环境中构建一致的网格。选择Istio的原因

相比之下，Cilium 1.19.6官方文档明确指出，相互认证处于Beta阶段，功能尚未完善。目前也不支持单一信任域的多集群配置，并且与外部mTLS解决方案的兼容性也存在限制。 Cilium Mutual Authentication 限制

如果mTLS和工作负载身份是购买决策的首要标准，那么Istio是一个更保守的选择。

2. 当复杂的L7流量控制是核心时

Istio以VirtualService和DestinationRule为中心，广泛提供以下功能：

基于头部和URI的路由
基于比例的金丝雀发布和A/B测试
按请求的超时和重试
熔断和异常检测
故障注入
流量镜像
包含外部服务和VM的ServiceEntry

这些功能已与Envoy数据平面长期协同运行。 Istio Traffic Management 官方文档

尽管Cilium也通过Gateway API和CiliumEnvoyConfig扩展了L7流量控制范围，但如果复杂的应用流量策略和Envoy扩展生态系统是核心，那么Istio会更熟悉和功能更丰富。

3. 当需要与CNI独立的网格时

Cilium的集成既是优点也是耦合。Cilium服务网格功能以Cilium CNI和eBPF数据路径为前提。

反之，Istio是与CNI分离的服务网格，因此当集群的CNI不同、需要将Kubernetes和VM一起绑定，或者不应依赖于特定的网络实现时，Istio更具优势。

4. 当Istio ambient已满足要求时

仅仅因为“不喜欢sidecar”而放弃现有的Istio是没有必要的。

Istio ambient通过节点级的ztunnel处理mTLS、L4授权和遥测，并在需要L7的命名空间中添加waypoint。如果目标是在保持现有Istio策略和运营经验的同时降低sidecar成本，那么转向ambient可能比重新构建Cilium更实际。 Istio ambient 官方概述

意外的答案：Cilium和Istio也可以一起使用

并非必须在这两款产品中只选择一个。

Cilium可以负责高性能CNI、eBPF kube-proxy替代、NetworkPolicy和Hubble，而Istio则负责mTLS、L7流量管理和服务网格。

Cilium官方文档提供了在Cilium网络之上使用Istio sidecar和ambient模式的集成方法。 Cilium与Istio集成官方文档

这种配置在以下情况下是合理的：

希望保留Cilium网络和Hubble。
需要Istio成熟的mTLS和L7策略。
不想一次性替换网络和网格。
组织的网络团队和应用平台团队职责分离。

当然，组件增多意味着故障点和升级组合也随之增加。这并非“两者都用最好”，而应仅在集成带来的功能优势大于运营复杂性时才选择。

选择标准一览表


要求	Cilium更适用	Istio更适用
已在使用Cilium CNI	是	需要额外添加网格层
kube-proxy替代和网络策略集成	优势	不在职责范围
L3·L4为主，部分L7	优势	ambient也是不错的替代方案
基于Hubble的网络·安全流分析	优势	提供以代理为中心的可观测性
复杂的重试、超时、故障和镜像	需审查限制	优势
成熟的服务mTLS和授权	需审查Beta状态	优势
VM和异构·多集群网格	需审查限制	优势
CNI独立性	低	高
以Gateway API为中心的Kubernetes运营	优势	同样支持，需比较所需功能
消除按Pod的sidecar	基本结构	可通过ambient实现

—

实际引入前应测量什么？

仅凭产品介绍资料做决定，很容易陷入“eBPF所以快”或“Envoy所以重”的简单结论。

最好是使用相同的工作负载和策略，搭建一个小型验证环境，并测量以下项目：

性能与成本

L4和L7流量各自的p50·p95·p99延迟时间
每秒请求数和连接数
节点和Pod的CPU·内存使用量
Envoy、ztunnel和waypoint的资源使用量
故障和滚动更新期间连接的保持情况

运营复杂性

安装的DaemonSet、Deployment和CRD数量
应用部署时对sidecar或注解的依赖性
策略更改反映到实际数据平面的时间
升级时Pod重启和服务影响
查找故障原因所需的工具和平均时间

功能适用性

所需L7协议和路由规则的支持情况
mTLS、身份和授权要求
多集群、多网络和VM支持情况
Gateway API一致性和所需扩展功能
审计日志和分布式追踪要求

最终决定不应仅仅基于一个基准测试数字，而应基于团队实际运营的功能和故障模式。

结论：Cilium的优势在于集成而非速度

将Cilium优于Istio的原因总结为一句话：

因为它能够将Kubernetes网络的起点CNI，到安全策略、服务负载均衡、可观测性以及可选的L7处理，连接成一个基于eBPF的统一运营模型。

这一优势对于已经使用Cilium、Kubernetes是基础设施核心、L3·L4流量较多，并且只需要在必要之处应用L7功能的组织来说最为显著。

反之，如果成熟的mTLS、复杂的L7流量管理、VM和异构多集群是核心需求，那么Istio可能更适用。Istio ambient在很大程度上减少了sidecar的缺点这一事实也应一并考虑。

因此，问题不应止于“Cilium比Istio快吗？”

我们组织真正需要回答的问题是：

将网络和服务网格整合到一个平台更重要，还是一个独立于网络的成熟L7服务网格更重要？

如果是前者，Cilium是强有力的竞争者。如果是后者，Istio依然强大。如果这两个需求都同样重要，那么在Cilium CNI之上运行Istio的组合也值得充分考虑。