Istio: A Service Mesh for Security, Traffic and Telemetry

Istio is a service mesh: a dedicated infrastructure layer that handles how services talk to each other. It encrypts traffic between services with mutual TLS, enforces who may call whom, controls routing (retries, timeouts, canary splits, fault injection) and emits consistent metrics, logs and traces for every request, all without changes to application code. It addresses a problem that grows with every microservice: each team re-implementing security, resilience and observability in its own libraries and languages, inconsistently. Istio was launched in 2017 by Google and IBM, built on the Envoy proxy created at Lyft. It joined the CNCF as an incubating project in September 2022 and graduated in July 2023.

CNCF daily · Sprint 1, day 2 · Service Mesh

At a glance

Category	Service Mesh
CNCF status	Graduated. Accepted September 2022 (Incubating); graduated July 12, 2023
Written in	Go (control plane), C++ (Envoy), Rust (ztunnel)
License	Apache 2.0
Data plane modes	Sidecar (an Envoy proxy per pod) or ambient (per-node ztunnel plus optional waypoint proxies)
Control plane	istiod: configuration, certificate authority and service discovery
APIs	Istio APIs (VirtualService, DestinationRule, AuthorizationPolicy) and Kubernetes Gateway API

Architecture

The diagram shows ambient mode, the newer sidecar-free data plane, which reached general availability in Istio 1.24.

flowchart TB
  subgraph CP[Control plane]
    ISTIOD[istiod<br/>config, CA, discovery]
  end
  CLIENT[External users] --> GW[Ingress gateway<br/>Envoy, Gateway API]
  subgraph NODE1[Node 1]
    ZT1[ztunnel<br/>L4 mTLS, identity]
    A[Service A pods]
  end
  subgraph NODE2[Node 2]
    ZT2[ztunnel<br/>L4 mTLS, identity]
    B[Service B pods]
  end
  WP[Waypoint proxy<br/>L7 routing, policy]
  GW --> A
  A --> ZT1
  ZT1 -->|HBONE mTLS tunnel| WP
  WP -->|HBONE mTLS tunnel| ZT2
  ZT2 --> B
  ISTIOD -.->|xDS config, certificates| GW
  ISTIOD -.-> ZT1
  ISTIOD -.-> ZT2
  ISTIOD -.-> WP
  ZT1 --> TEL[Metrics, traces, logs<br/>Prometheus, OpenTelemetry]
  WP --> TEL

Component	Responsibility
istiod	Single control-plane binary: translates Istio and Gateway API resources into Envoy configuration, issues workload certificates (SPIFFE identities) and watches Kubernetes for services and endpoints.
Sidecar proxy	In sidecar mode, an Envoy container injected into each pod that intercepts all inbound and outbound traffic.
ztunnel	In ambient mode, a per-node Rust proxy that provides mTLS, identity and L4 policy for every pod on the node.
Waypoint proxy	In ambient mode, an optional Envoy deployment per namespace or service that adds L7 features: HTTP routing, retries, header-based policy.
Gateways	Envoy deployments at the edge of the mesh for ingress and egress traffic.

Design principle. Istio moves cross-cutting network concerns out of application code and into the platform, configured declaratively and applied uniformly. Every workload gets a cryptographic identity, so security policy can say “the orders service may call payments” instead of relying on IP addresses. Ambient mode keeps that model while removing the per-pod sidecar, cutting resource overhead and making the mesh easier to adopt and upgrade.

Production reference design

Ambient mode on EKS, GKE, AKS or on-premises Kubernetes, enabled namespace by namespace:

1. Install Istio with the ambient profile using istioctl (or the official Helm charts in GitOps):

   istioctl install --set profile=ambient --skip-confirmation
   kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/<version>/standard-install.yaml

2. Enrol a namespace in the mesh. Its pods immediately get mTLS and identities through ztunnel, without restarts:

   kubectl label namespace payments istio.io/dataplane-mode=ambient

3. Require mutual TLS and restrict access with identity-based policy:

   apiVersion: security.istio.io/v1
   kind: PeerAuthentication
   metadata: { name: default, namespace: payments }
   spec:
     mtls: { mode: STRICT }
   ---
   apiVersion: security.istio.io/v1
   kind: AuthorizationPolicy
   metadata: { name: allow-orders, namespace: payments }
   spec:
     action: ALLOW
     rules:
       - from:
           - source:
               principals: ["cluster.local/ns/orders/sa/orders-api"]

4. Add a waypoint for L7 features where they are needed, for example a 90/10 canary split between two versions through a Gateway API HTTPRoute:

   istioctl waypoint apply --namespace payments --enroll-namespace

5. Wire telemetry to Prometheus, Grafana and an OpenTelemetry collector for traces, and use Kiali to visualise service-to-service traffic and policy.

Typical production uses include zero-trust networking between microservices, compliance requirements for encryption in transit, progressive delivery (canary and blue-green with Argo Rollouts), multi-cluster service connectivity and uniform golden-signal metrics across all services.

Operational considerations

• Choose the data plane mode first. Ambient mode has lower overhead and simpler upgrades; sidecar mode is the longer-established option with the widest feature coverage. New installations should generally start with ambient.
• Plan upgrades carefully. Use revision-based (canary) control-plane upgrades and follow the supported version skew; Istio releases roughly quarterly.
• Mind resource costs. Sidecars add CPU and memory to every pod; size them, or move to ambient. Waypoints should only be deployed where L7 features are actually needed.
• Roll out policy gradually. Start in permissive mTLS mode, observe traffic, then switch namespaces to STRICT and add authorisation policies to avoid outages.
• Debugging needs new skills. Learn istioctl analyze, proxy configuration dumps and Kiali; many “network” incidents in a mesh are configuration issues.

Adoption

• The CNCF graduation announcement names end users including eBay, T-Mobile, Airbnb and Salesforce.
• Istio is offered as a managed or supported service by major vendors, including Google Cloud Service Mesh, Red Hat OpenShift Service Mesh and Azure Kubernetes Service’s Istio add-on.
• Maintainers come from more than 16 organisations, including Google, IBM, Red Hat, Solo.io, Tetrate and Microsoft, whose Open Service Mesh team joined Istio.

Alternatives

Solution	Model	Best suited to
Linkerd (CNCF Graduated)	Lightweight Rust micro-proxy sidecars	Teams that want a simpler mesh with fewer features to operate
Cilium Service Mesh (Cilium is CNCF Graduated)	eBPF-based, sidecar-free networking with Envoy for L7	Clusters already using Cilium as their CNI
Consul service mesh	Mesh across Kubernetes and VMs	Mixed estates with HashiCorp tooling
Kuma (CNCF Sandbox)	Envoy-based mesh for Kubernetes and VMs	Multi-zone meshes with a simpler control plane
Application libraries (gRPC, Spring Cloud)	Resilience and security in code	Small estates with one language and few services

Strengths and limitations

Strengths	Limitations
Automatic mTLS and identity-based authorisation	Significant conceptual and operational complexity
Rich traffic management: canaries, retries, timeouts, fault injection	Sidecar mode adds per-pod resource and latency overhead
Uniform telemetry for every service without code changes	Upgrades and configuration errors can affect the whole mesh
Ambient mode removes sidecars and simplifies adoption	Ambient is newer, with fewer production years than sidecar mode
Graduated, vendor-neutral and widely supported	Overkill for a handful of services

Recommendation

Adopt Istio when you run many services and need zero-trust security, traffic control and consistent telemetry across them; start new meshes in ambient mode and enrol namespaces gradually. Assess Linkerd or Cilium’s mesh if simplicity matters more than breadth of features, and skip a mesh entirely for small estates where library-level retries and TLS are enough.

References: CNCF project page · CNCF: Istio graduation announcement · Istio documentation · Istio ambient mode overview