Istio vs. Linkerd vs. Cilium: service mesh compared

Plan the cluster network properly: WZ-IT designs and operates Kubernetes networks with CNI, network policies, Gateway API, DNS and TLS. View Network & Secure Access

A service mesh moves encryption, access rules, traffic control and metrics between services out of application code and into the infrastructure. That only pays off if one of these tasks is genuinely open in the cluster, because every mesh adds a data plane, its own releases and its own failure modes. This article first clarifies when a mesh is unnecessary, then compares Istio (sidecar and ambient), Linkerd and Cilium Service Mesh based on the project documentation. As of 28 October 2026.

Table of contents

• Do you need a service mesh at all?
• The three candidates
• Istio, Linkerd and Cilium compared
• Resource use according to the projects
• Operational risks with sources
• Gateway API and the mesh
• Decision table
• Start without a mesh
• Status and methodology
• Our approach at WZ-IT
• Further guides

Do you need a service mesh at all?

The Cilium documentation summarizes the tasks of a mesh as resilient connectivity across cluster boundaries, L7-aware traffic control, identity-based security and observability, all transparent to the application (Cilium: Service Mesh). In practice this comes down to five tasks, which can be partly solved without a mesh:

Our assessment: A mesh is justified if at least one row in the right-hand column applies and the alternative costs more. We do not name a minimum number of services, because the need depends on requirements, not on the number of deployments. If no row applies, the mesh is unnecessary; Start without a mesh describes the path.

The three candidates

Istio: sidecar and ambient

Istio consists of the istiod control plane and a data plane in two modes (Sidecar or ambient). In sidecar mode an Envoy proxy has run in every pod since 2017. In ambient mode a ztunnel written in Rust, one per node (DaemonSet), handles mTLS, L4 authorization and L4 telemetry. L7 features come from optional Envoy-based waypoint proxies that are installed, upgraded and scaled separately from the applications (ambient overview). An Istio installation with ambient support is called an "ambient mesh" in the documentation. The mode has been generally available since Istio 1.24 (November 2024) (Istio blog). The current version is Istio 1.31.3 from 22 October 2026 (release); a minor version is supported until six weeks after the release of the minor version after next (support policy).

Limits of ambient according to the migration guide: VM workloads cannot join, SPIRE as a certificate source is not supported, EnvoyFilter does not apply to waypoints, and VirtualService is alpha there, with HTTPRoute as the intended replacement.

Linkerd: license and release model

Linkerd uses a Rust micro-proxy as a sidecar in every pod (architecture), as a native sidecar container by default since version 2.20 (2.20 announcement). mTLS is active by default for TCP traffic between meshed pods (Automatic mTLS).

On the release model: since Linkerd 2.15 (February 2024) the open source project no longer provides stable release artifacts, which is now left to the vendor community (2.15 announcement). The releases page lists only Buoyant Enterprise for Linkerd (BEL) as a distribution. The project continues to publish edge releases (currently edge-26.10.1) and generally considers them production ready. According to the Buoyant pricing page, the open source plan lacks stable releases with semantic versioning and CVE remediation SLAs. BEL is free to try, companies with fewer than 50 employees may run it in production; beyond that Buoyant offers the Premium and Strategic plans. The page does not state prices (retrieved 28 October 2026).

Cilium Service Mesh

Cilium is first of all a CNI with an eBPF data path. The mesh functions come on top: Gateway API, GAMMA, L7 policy through one Envoy per node (Gateway API), visibility through Hubble and transparent encryption. Mutual authentication via SPIFFE and SPIRE is marked beta in the 1.20 documentation; the items "Per-connection handshake" and "Integrate with WireGuard" are still TODO, and clusters in a Cluster Mesh are not compatible (Mutual Authentication). Cilium shows only L3/L4 events by default; L7 visibility arises from L7 rules in a CiliumNetworkPolicy, which restrict the traffic at the same time (visibility). The current version is Cilium 1.20.4 from 23 October 2026 (release).

Istio, Linkerd and Cilium compared

The Gateway API classification comes from the implementations list: under "Service Mesh Implementation Status" it lists Cilium and Istio as conformant, and Linkerd does not appear.

Two Istio pages contradict each other on the maturity of Istio multicluster: the feature status lists "Multicluster Mesh" and, for ambient, "Multi-network multicluster" as beta, while the page on the data plane modes calls sidecar mode "Stable, including multi-cluster". The table follows the feature status because it states maturity per feature. For ambient, the installation guide states: beta, multi-primary only and multi-network only.

Resource use according to the projects

We found current CPU and memory figures with a disclosed method only for Istio. For version 1.24, the performance page states at 1,000 HTTP requests per second with a 1 KB payload:

In its comparison of the modes, Istio puts latency (p90/p99) at 0.63 to 0.88 ms for sidecars, 0.16 to 0.20 ms for ambient and 0.40 to 0.50 ms with a waypoint. The latency charts on the performance page were produced on a bare-metal cluster with Flannel at 500 to 1,500 requests per second with mTLS enabled; other hardware gives other values. For Linkerd, the project blog carries two comparisons with Istio: one from 2021 with CPU, memory and latency figures that predates Istio's ambient mode (2021 benchmark), and one from 24 April 2025 with Istio ambient that reports only latencies at 20, 200 and 2,000 requests per second on GKE (2025 benchmark). Both come from the Linkerd side and are not vendor-neutral. In the Cilium documentation on service mesh, Gateway API, GAMMA and encryption (1.20) we found no resource figures for the mesh functions. Comparing the three therefore requires a test with your own workload.

Operational risks with sources

Istio

• Ambient with L7 features needs waypoint proxies, that is, additional Envoy deployments that are installed, upgraded and scaled separately (overview).
• With Cilium as CNI, ambient needs cni.exclusive=false; BPF masquerading is not supported, and a default-deny policy blocks the kubelet health probes until a CiliumClusterwideNetworkPolicy allows them (platform prerequisites). On k3s with its bundled CNI the platform flag global.platform=k3s is required; with a custom CNI such as Cilium, the CNI paths must be set instead.
• Migrating to ambient with L7 policies leaves a window in which these rules are not enforced until the waypoint policies take effect (migration).

Linkerd

• The trust anchor generated by linkerd install expires after 365 days and must be rotated manually, or you generate it yourself with a longer lifetime. The issuer certificate also expires after one year, and its rotation can be automated with cert-manager. Multicluster requires a shared trust anchor (Automatic mTLS).
• Linkerd 2.20 lists Gateway API 1.2.1 to 1.5.1 as compatible and warns of hard-to-debug problems with other versions (Gateway API). Cilium 1.20 names Gateway API 1.6.3. Anyone running both checks the CRD version against both tables.

Cilium

• Gateway API and GAMMA require the kube-proxy replacement (kubeProxyReplacement=true); GAMMA supports only producer routes, not consumer routes (GAMMA).
• Cilium and Istio together: use L7 policy in only one of the two systems, otherwise the Cilium documentation warns of split-brain effects (integration with Istio).

Gateway API and the mesh

The GAMMA initiative configures mesh routing with the same routes as ingress, by binding an HTTPRoute to a service instead of a gateway. Istio lists "Gateway APIs for mesh" as stable in its feature status, Cilium supports only producer routes, and Linkerd uses HTTPRoute and GRPCRoute for policies, timeouts and routing. Anyone who introduces the Gateway API at the edge works in the same routing format that Istio waypoints and Linkerd use for mesh routing. The background is in Gateway API vs. Ingress.

Decision table

Istio or Linkerd? Both provide mTLS, L7 routing and metrics, and both attach non-Kubernetes workloads (Istio in sidecar mode, Linkerd via mesh expansion since 2.15). Linkerd names operational simplicity as a goal (2.20 announcement); according to its architecture documentation its data plane consists of sidecar proxies. Istio additionally offers ambient mode with ztunnel and waypoints. On the other side, Linkerd raises the question of how to obtain stable releases and Istio the breadth of its configuration. The table is our assessment based on the cited sources, not a benchmark.

Start without a mesh

1. Gateway API at the edge: HTTPRoutes with weights for canary releases, TLS at the gateway.
2. Default deny per namespace with NetworkPolicy; the CNI comparison is in Cilium vs. Calico.
3. Encryption with WireGuard when Cilium is the CNI and transport encryption is required.
4. Visibility through Hubble and metrics from the applications.
5. Decision point: if one of the requirements from the first section applies, start a pilot in one namespace. With Istio ambient the label istio.io/dataplane-mode=ambient is enough, without restarting pods; with Linkerd it is the annotation linkerd.io/inject followed by a rollout.

In sidecar mode an Istio workload accepts plaintext and mTLS by default (PERMISSIVE) without authenticating the plaintext traffic (mTLS migration); the switch to STRICT follows once all callers are in the mesh. Ambient always enforces mTLS between mesh workloads (migration guide).

Status and methodology

As of 28 October 2026. The basis is exclusively primary sources: the linked project pages (Istio, Linkerd, Buoyant, Cilium, Gateway API, CNCF) and the Kubernetes documentation, retrieved on 28 October 2026. Versions: Istio 1.31.3, Linkerd 2.20 (latest edge release edge-26.10.1), Cilium 1.20.4, Gateway API 1.6.3 according to the GitHub releases. The resource figures come from Istio for version 1.24; the latency values on Istio's page comparing the data plane modes name no version. We ran no measurements of our own. Buoyant does not publish prices. The decision table and the assessment at the start are our evaluation. The limits described can change with new releases; the linked pages are authoritative.

Our approach at WZ-IT

Network planning with CNI, network policies, Gateway API, DNS and TLS is part of building a Kubernetes cluster at WZ-IT (Network & Secure Access). The first two steps from Start without a mesh, Gateway API at the edge and default deny with network policies, fall within that scope. The operation of the cluster itself is described under Managed Kubernetes.

Further guides

• Gateway API vs. Ingress
• Cilium vs. Calico
• Migrate from ingress-nginx to the Gateway API
• Access Kubernetes privately with NetBird
• Kubernetes glossary: the key terms explained

Plan the Kubernetes network: Kubernetes Network & Secure Access covers CNI, network policies, Gateway API, DNS, TLS and private access.

Related service: Cilium and network policies