Skip to content

Service Mesh

Service mesh platforms and API gateway solutions for Kubernetes — providing mTLS encryption, traffic management, observability, and Layer 7 policy enforcement between services.

← Knowledge Base

Topics

Tool Description
Envoy Gateway Kubernetes-native API gateway built on Envoy Proxy — the official reference implementation of the Kubernetes Gateway API.
Istio Industry-standard service mesh with Ambient Mode (sidecar-free), mTLS, L7 traffic management, and AI inference routing.
Linkerd Ultralight Rust-based service mesh — CNCF Graduated, simplest to operate, with automatic mTLS and post-quantum cryptography.

Comparisons

Comparison Scope
Service Mesh Comparison Envoy Gateway vs Istio vs Linkerd — architecture, operational complexity, performance, and security model

Landscape

The service mesh landscape is undergoing a fundamental architectural shift away from sidecar proxies toward sidecar-less models that reduce resource overhead and operational complexity. Istio's Ambient Mode (GA in v1.24, November 2024) replaces per-pod Envoy sidecars with a shared ztunnel DaemonSet for L4 mTLS and optional waypoint proxies for L7 policy — cutting memory overhead by 90%+ for workloads that only need mutual TLS.

Linkerd continues to champion the sidecar model but with its ultralight Rust-based linkerd2-proxy (under 10 MB RSS per sidecar), arguing that per-pod proxies provide stronger security isolation. The Kubernetes Gateway API has become the unifying configuration interface: Envoy Gateway is the official reference implementation, Istio maps its VirtualService/DestinationRule CRDs to Gateway API resources, and Linkerd has adopted HTTPRoute for traffic splitting.

Industry Consolidation

Industry consolidation is evident — Buoyant (Linkerd's parent company) shifted to a source-available license in 2024, while Istio graduated from CNCF in July 2023, signaling enterprise maturity. The GAMMA (Gateway API for Mesh Management and Administration) initiative aims to extend Gateway API from north-south (ingress) to east-west (service-to-service) traffic management, potentially unifying mesh configuration across vendors.

The debate is no longer whether to use a mesh, but which mesh architecture (ambient vs sidecar vs CNI-integrated) best fits the workload profile. CNI-integrated meshes like Cilium's built-in service mesh blur the boundary between network infrastructure and application-level traffic management, offering mTLS and L7 policy without a separate mesh control plane.

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: Uses an internal CA (istiod) or integrates with cert-manager/Vault. Default certificate TTL is 24 hours. Supports custom root CAs and intermediate CA chaining.
  • Linkerd: Uses its own trust anchor with a 24-hour identity certificate lifetime. Supports bringing your own trust anchor for cross-cluster mTLS.
  • Ambient mode (ztunnel): mTLS is handled at the node level rather than per-pod, using HBONE tunneling over HTTP/2 CONNECT.

This eliminates the need for application-level TLS configuration and provides the foundation for identity-based authorization policies — mesh AuthorizationPolicy resources can allow or deny traffic based on the peer's SPIFFE identity rather than IP addresses.

Traffic Management

Key Capabilities

  • Traffic splitting: Route a percentage of traffic to canary versions (e.g., 5% to v2, 95% to v1) using weighted backends in HTTPRoute or Istio VirtualService.
  • Request routing: Route based on HTTP headers, paths, or gRPC methods — enabling header-based staging environments or A/B testing.
  • Fault injection: Inject latency or HTTP errors to test resilience (Istio VirtualService fault injection, Linkerd's traffic split with error injection via ServiceProfile).
  • Retries and timeouts: Automatically retry failed requests with configurable budgets and deadline propagation to prevent retry storms.
  • Circuit breaking: Limit concurrent connections and pending requests to prevent cascade failures (Istio DestinationRule outlier detection, Linkerd's failure accrual).

Sidecar vs Ambient Architecture

The sidecar model injects a proxy container (Envoy for Istio, linkerd2-proxy for Linkerd) into every pod, intercepting all inbound and outbound traffic via iptables REDIRECT rules. This provides strong per-pod isolation but doubles the container count and consumes significant memory at scale. Istio's ambient mode replaces sidecars with two layers: a shared ztunnel node proxy (DaemonSet) handling L4 mTLS for all pods on the node, and optional per-namespace waypoint proxies (Envoy deployments) for workloads requiring L7 policy. This layered approach lets organizations pay the L7 cost only where needed.

Control Plane

The management layer that configures and coordinates the data plane proxies across the mesh. Istio consolidated its control plane into a single istiod binary (Pilot for config, Citadel for CA, Galley for validation) that pushes Envoy configuration via xDS protocol. Linkerd's control plane includes the destination controller (service discovery), identity controller (mTLS CA), and proxy-injector (sidecar injection webhook). The control plane is the single point of configuration — operators declare intent (e.g., "all traffic between namespace A and B must be encrypted") and the control plane translates this into data plane configuration.

Data Plane Proxy

The network proxy that intercepts and processes traffic on behalf of application workloads. Envoy (used by Istio and Envoy Gateway) is a C++-based L7 proxy with extensive filter chains, WASM extensibility, and xDS dynamic configuration. Linkerd2-proxy is a purpose-built Rust micro-proxy optimized for service mesh use cases — it lacks Envoy's general-purpose extensibility but achieves lower latency (sub-millisecond p99 overhead) and memory usage. In Istio's ambient mode, ztunnel is a Rust-based L4 proxy that handles mTLS with HBONE (HTTP-based overlay network) tunneling, and Envoy serves as the waypoint proxy for L7.

Open Questions

  • Will Istio's ambient mode effectively end the sidecar-vs-sidecarless debate, or will Linkerd's argument for per-pod isolation remain compelling for security-sensitive workloads in regulated industries?
  • As CNI plugins like Cilium add L7 traffic management and mTLS capabilities, does the service mesh become a redundant layer — or do mesh-specific features (traffic splitting, fault injection, retry budgets) remain valuable enough to justify the added component?
  • How does the Gateway API's expansion into mesh use cases (GAMMA initiative — Gateway API for Mesh Management and Administration) affect the proprietary CRD ecosystems of Istio and Linkerd?