Skip to content

Service Mesh

Summary

Service meshes and Gateway API gateways for Kubernetes. The two meshes, Istio and Linkerd, manage east-west (service-to-service) traffic: automatic mTLS with workload identity, L7 routing, retries, circuit breaking, authorization, and telemetry. Envoy Gateway manages north-south (edge) traffic through the Kubernetes Gateway API and is not a mesh. The Gateway API is the shared configuration layer for all three, and the retirement of the community Ingress-NGINX controller (maintenance ended March 2026) is pushing ingress onto it.

← Knowledge Base

Domain Map

How the three topics relate: Envoy Gateway at the edge, a mesh inside the cluster, and the Gateway API as the shared configuration interface.

flowchart LR
    NGINX["Ingress-NGINX<br/>(retired, maintenance ended 2026-03)"] -.->|"ingress2gateway 1.0"| GAPI
    GAPI["Kubernetes Gateway API<br/>Gateway, HTTPRoute, GRPCRoute<br/>GAMMA for mesh routes"]
    GAPI --> EG["Envoy Gateway<br/>north-south, Envoy fleet per Gateway"]
    GAPI --> ISTIO["Istio<br/>sidecar or ambient (ztunnel + waypoints)"]
    GAPI --> LINKERD["Linkerd<br/>linkerd2-proxy sidecars"]
    EG -->|"base layer for"| AR["Agent Router<br/>(formerly Envoy AI Gateway)"]
    EG -->|"edge traffic into the mesh"| ISTIO
    EG -->|"edge traffic into the mesh"| LINKERD
    ENVOY["Envoy Proxy (CNCF Graduated)"] -.->|"data plane"| EG
    ENVOY -.->|"sidecars, gateways, waypoints"| ISTIO

Topics

Topic Description Latest Version License
Envoy Gateway Envoy project's control plane for running Envoy as a north-south gateway. One of many conformant Gateway API implementations, with typed policy CRDs for auth, rate limiting and extensions. Base layer for Agent Router. v1.9.1 (2026-08-28) Apache-2.0
Istio CNCF Graduated, Envoy-based mesh with two data plane modes: sidecars, or ambient (per-node ztunnel for L4, optional Envoy waypoints for L7, GA since 1.24). Richest L7 feature set, AI inference routing (beta). 1.31.1 (2026-09-21) Apache-2.0
Linkerd CNCF Graduated mesh built on the Rust linkerd2-proxy sidecar. mTLS by default with post-quantum hybrid key exchange, EWMA load balancing, few knobs. OSS ships edge releases only. 2.20 (2026-06-23); edge edge-26.9.3 (2026-09-16) Apache-2.0 (stable BEL builds need a Buoyant license)

Comparisons

Comparison Scope
Service Mesh Comparison Envoy Gateway vs Istio vs Linkerd: release models, data plane architectures, feature matrix, sourced resource figures, decision flowchart, combining an edge gateway with a mesh

All comparison notes: Comparisons index.

When to Use Which

The short version of the decision guide:

If you need Start with
Ingress only, or a replacement for Ingress-NGINX Envoy Gateway (or the Gateway API implementation of a mesh or CNI you already run)
East-west mTLS with the least operational effort Linkerd
mTLS for many services without per-pod sidecars, L7 only where needed Istio ambient mode
Wasm or custom Envoy behaviour, end-user JWT at the mesh, AI inference routing Istio
OSS stable semver releases without a vendor license Istio or Envoy Gateway (Linkerd OSS ships edge releases only)
Edge and mesh together Envoy Gateway at the edge plus Istio or Linkerd inside (see Complementary Usage)

Landscape

The mesh landscape is shifting from per-pod sidecars toward sidecar-less data planes that cut resource overhead and operational churn. Istio ambient mode (GA in 1.24, November 2024) replaces per-pod Envoy sidecars with a per-node ztunnel for L4 mTLS and optional waypoint proxies for L7 policy. In Istio's own load tests (Istio 1.24, 1000 RPS, 1 KB payloads) a ztunnel used about 12 MB and 0.06 vCPU per node, against about 60 MB and 0.20 vCPU per pod for a sidecar (Istio reference). The actual saving depends on pods per node and on how many namespaces need a waypoint (about 60 MB each).

Linkerd keeps the sidecar model with its purpose-built Rust proxy, and since 2.20 injects it as a Kubernetes native sidecar by default. The only published head-to-head numbers are Buoyant's 2021 benchmark (17.8 MB vs 154.6 MB maximum proxy memory against an Istio 1.10 sidecar); no benchmark against Istio ambient exists (Linkerd reference). The project argues that per-pod proxies are a stronger security boundary.

The Kubernetes Gateway API is now the common configuration interface. Envoy Gateway is one of many conformant implementations listed by the Gateway API project, which does not name an official reference implementation. Istio supports both its classic APIs (VirtualService, DestinationRule) and Gateway API, and recommends Gateway API for new work (ingress, waypoints, and GAMMA mesh routing). Linkerd 2.14 was the first mesh conformant with the GAMMA Mesh profile and now uses Gateway API HTTPRoute/GRPCRoute as its primary routing interface.

Governance and licensing

Istio graduated in the CNCF on 2023-07-12 and has multi-vendor maintainers. Linkerd graduated on 2021-07-28; all of its maintainers work for Buoyant. In February 2024 Linkerd changed its release model, not its license: the code is still Apache-2.0 and edge releases stay free, but stable, semver-versioned artifacts now come only from vendors, mainly Buoyant Enterprise for Linkerd (free for companies with fewer than 50 employees, per Buoyant). Envoy Gateway is a sub-project of Envoy (CNCF Graduated). Its AI extension, Envoy AI Gateway, was renamed Agent Router on 2026-09-10 and joined the Agentic AI Foundation.

Ingress-NGINX retirement

Kubernetes announced the retirement of the community Ingress-NGINX controller on 2025-11-11, and best-effort maintenance ended in March 2026 with no further security fixes. Gateway API is the designated successor. ingress2gateway 1.0 converts Ingress resources and has an envoy-gateway emitter. See Envoy Gateway: migrate from Ingress-NGINX.

The debate is no longer whether to use a mesh, but which data plane architecture (sidecar, ambient, or CNI-integrated) fits the workload. CNI-integrated meshes such as Cilium's sidecar-free mesh (eBPF plus a per-node Envoy) blur the boundary between network infrastructure and application-level traffic management, and Calico 3.32 bundles Istio ambient mode (tech preview).

Key Concepts

mTLS (Mutual TLS)

Mutual TLS provides both encryption and cryptographic identity verification between communicating services: each side presents a certificate and validates the peer's certificate. In a service mesh, mTLS is transparent to applications: the mesh control plane acts as a certificate authority and automatically rotates short-lived certificates.

Certificate management details by mesh:

  • Istio: istiod's built-in CA issues SPIFFE certificates (spiffe://<trust-domain>/ns/<ns>/sa/<sa>) with a 24-hour default lifetime. It can use plugged-in intermediate certificates or an external signer. The default PeerAuthentication mode is PERMISSIVE; set STRICT to reject plaintext. See Istio: Security Model.
  • Linkerd: the identity controller issues 24-hour leaf certificates from an issuer certificate chained to your trust anchor. Clusters linked for multicluster must share a trust anchor. Since 2.19 all meshed traffic uses TLS 1.3 with hybrid ML-KEM-768 + X25519 key exchange. See Linkerd: Identity, mTLS and the Trust Chain.
  • Istio ambient (ztunnel): mTLS is terminated in the per-node ztunnel rather than per pod, using HBONE (HTTP/2 CONNECT on port 15008).

This removes application-level TLS configuration and provides the basis for identity-based authorization: mesh authorization policies allow or deny traffic based on the peer's workload identity rather than IP addresses.

Traffic Management

Key Capabilities

  • Traffic splitting: route a percentage of traffic to canary versions (for example 5% to v2, 95% to v1) with weighted backendRefs in an HTTPRoute, or with an Istio VirtualService.
  • Request routing: route on HTTP headers, paths, or gRPC methods for header-based staging or A/B testing.
  • Fault injection: inject latency or errors to test resilience. Istio has native delay/abort faults. Linkerd uses a weighted HTTPRoute split to an error-injecting backend. Envoy Gateway configures faults in BackendTrafficPolicy.
  • Retries and timeouts: retry failed requests with budgets and deadlines to avoid retry storms (Istio routes, Linkerd annotations on Gateway API routes, EG BackendTrafficPolicy).
  • Circuit breaking: eject failing endpoints and cap concurrent requests to prevent cascading failures (Istio DestinationRule connectionPool and outlierDetection, Linkerd failure accrual, EG BackendTrafficPolicy).

Sidecar vs Ambient Architecture

The sidecar model injects a proxy (Envoy for Istio, linkerd2-proxy for Linkerd) into every pod and redirects the pod's traffic through it with iptables or nftables rules. This gives strong per-pod isolation, but proxy cost scales with pod count and proxy upgrades need pod restarts. Istio ambient mode replaces sidecars with two layers: a shared ztunnel DaemonSet that handles L4 mTLS for all pods on the node, and optional waypoint proxies (Envoy Deployments per namespace or service) for workloads that need L7 policy. Organizations pay the L7 cost only where they need it. The comparison has a diagram of both models next to an edge gateway.

Control Plane

The control plane configures and coordinates the data plane proxies. Istio runs a single istiod binary that serves xDS configuration, acts as the CA, and runs the injection and validation webhooks. The older component names (Pilot for configuration, Citadel for the CA, Galley for validation) are historical; they survive mainly in the pilot-discovery/pilot-agent binaries and PILOT_* environment variables. The Linkerd control plane consists of linkerd-destination (service discovery and policy), linkerd-identity (the mTLS CA), and linkerd-proxy-injector (the injection webhook). Envoy Gateway's envoy-gateway controller translates Gateway API and EG policy resources into xDS and provisions the Envoy fleet. In each case operators declare intent (for example "all traffic between namespace A and B must be encrypted") and the control plane translates it into data plane configuration.

Data Plane Proxy

The data plane proxy intercepts and processes traffic on behalf of workloads. Envoy (used by Istio and Envoy Gateway) is a C++ L7 proxy with extensive filter chains, Wasm extensibility, and xDS dynamic configuration. linkerd2-proxy is a purpose-built Rust micro-proxy: no xDS, no filter chains, and no Wasm, which keeps its footprint and attack surface small at the cost of extensibility. In Istio ambient mode, ztunnel is a Rust L4 proxy that handles mTLS over HBONE, and Envoy serves as the waypoint proxy for L7.

Sources

Open Questions

  • Will Istio ambient mode end the sidecar-vs-sidecarless debate, or will Linkerd's argument for per-pod isolation stay compelling for security-sensitive, regulated workloads? Linkerd has published no sidecar-less design as of 2026-09. See Linkerd: Native Sidecars and Istio: Choosing Sidecar or Ambient.
  • As CNIs such as Cilium add L7 traffic management and mTLS (Cilium ztunnel mTLS is beta), does a separate mesh become redundant, or do mesh-specific features (fault injection, retry budgets, federated multicluster) keep it worthwhile? See the CNI comparison.
  • Will anyone publish an independent benchmark of Linkerd against Istio ambient mode? See Linkerd reference.
  • How will diverging Gateway API version ranges (Linkerd 2.20 up to v1.5.1, Istio 1.31 on v1.6.0, EG v1.9 on v1.6.1) be managed in clusters that run a mesh and a separate gateway?