Linkerd vs Cilium vs Istio 对比

⚡ 延迟测试（Latency Testing）

测试工具：oha
向同一命名空间下的 nginx Pod 发送 100,000 个 HTTP 请求以测试延迟。

oha http://nginx -c 32 -n 100000 --disable-keepalive --disable-compression --insecure --ipv4
  • $URL 是服务的 DNS 名称（例如 http://nginx）
  • $CONCURRENT_CONNECTIONS 是并发连接数
  • $REQUESTS 是总请求数

🧪 延迟测试结果（单位：毫秒）

并发连接数 / 延迟(ms) cilium cilium + L7策略 cilium + L4策略 linkerd istio istio + vs 无 Service Mesh
32 5.1 28.2 5.4 9.1 13.2 13.4 5.0
64 9.5 55.4 9.6 16.4 24.2 24.5 9.7
128 17.9 114.3 19.5 31.7 45.3 46.4 18.1

结论：

  1. 在 Service Mesh 中，Linkerd 延迟最低，而 Istio 功能最全面、效率最佳。
  2. Cilium 在 L4 流量管理下对性能影响较小。
  3. Cilium 处理 L7 流量时开销超过 Istio 的两倍，不适合高并发低延迟场景。

⚙️ QPS 测试结果（请求数/秒）

QPS cilium cilium + L7策略 cilium + L4策略 linkerd istio istio + vs 无 Service Mesh
32 6232 1132 5892 3529 2421 2328 6218
64 6705 1154 6678 3888 2648 2600 6575
128 7153 1119 6541 4034 2826 2758 7073

结论：

  1. 在启用 L7 代理时，Linkerd 的性能最佳。
  2. Cilium 在 L4 场景 下性能出色，但 启用 L7 策略后性能大幅下降。
  3. 默认情况下，Cilium 仅在 L3/L4 层启用网络策略。只有在 CiliumNetworkPolicy 中明确指定了 L7 规则（即使是空规则），Cilium 才会启用 Envoy 代理处理流量。

📶 吞吐测试（Throughput）

测试工具：iperf3
客户端持续向服务端发送数据，持续时间为 600 秒。

iperf3 -c iperf3-server -t 600 -i 1

吞吐测试结果：

Bitrate (Gbit/s) / Retr cilium + L4策略 cilium 无策略 linkerd istio istio + vs 无 Service Mesh
吞吐量（Gbit/s） 25.8 25.6 2.46 10.5 6.39 25.3
重传次数（Retr） 291376 319255 947 229 900 313936

结论：

  1. Linkerd 在大数据传输下性能开销明显，不适合高吞吐量网络场景。
  2. Cilium 不启用 L7 时，性能与无 Service Mesh 几乎持平。
  3. 在高带宽、高吞吐量场景下，Istio 的适配性优于 Linkerd。

🧾 总结

  1. 若对延迟敏感、流量不大，推荐使用 Linkerd。
  2. 若需复杂、细粒度的流量管理能力，推荐使用 Istio。
  3. 不建议使用 Cilium 做 L7 代理，因其带来的性能开销远高于其他方案。