Cloud Parts

Istio

The Kubernetes service mesh started by Google, IBM and Lyft: mutual TLS, traffic routing and telemetry between services, through Envoy sidecars or the sidecar-less ambient mode.

What it is
Service discovery & mesh
Type
Open source
Made by
Cloud Native Computing Foundation
License
Apache 2.0
Facts checked
6 October 2026
Website Source code

What it is

Istio has one control plane, istiod, and a choice of two data planes. istiod watches Kubernetes for services and endpoints, turns Istio’s routing and security resources into proxy configuration, and streams it to every proxy over Envoy’s xDS APIs. It is also a certificate authority: each workload gets an X.509 certificate for its service identity, issued through a certificate signing request and rotated automatically, so proxies can authenticate each other with mutual TLS. A permissive mode accepts both plain text and mTLS while you migrate; strict mode then refuses anything else.

In sidecar mode, a mutating admission webhook adds an Envoy proxy container to every pod, and all of the pod’s traffic passes through it. That gives full Layer 7 features everywhere: retries, timeouts, circuit breaking, percentage-based traffic splits for canary releases, and per-request metrics and traces. The cost is a proxy per pod, and pods must restart to pick up a new proxy version. Ambient mode, generally available since Istio 1.24 (November 2024), splits the work in two. A ztunnel, a small Rust proxy running once per node as a DaemonSet, handles Layer 4: it carries traffic between nodes in mTLS tunnels (HBONE, HTTP CONNECT over HTTP/2) and enforces simple policies. Where you need Layer 7, you deploy waypoint proxies, Envoy deployments that usually serve a whole namespace and scale independently of the apps.

Istio is free under Apache 2.0 and a CNCF graduated project. Routes can be written with Istio’s own resources (VirtualService, DestinationRule) or with the Kubernetes Gateway API, which the project intends to make the default. Google’s Cloud Service Mesh accepts Istio APIs, and Azure offers an Istio add-on for AKS, though that add-on doesn’t support ambient mode yet.

Why teams pick it

  • Mutual TLS between services with automatic certificate issuance and rotation, plus a permissive mode for gradual migration
  • Rich traffic control: weighted splits, retries, timeouts, fault injection and circuit breaking without changing application code
  • Two data planes: sidecars for full per-pod control, or ambient mode, which the project says can cut the mesh’s resource overhead by more than 90% in some cases
  • Widely adopted and well integrated: Prometheus metrics, ready-made Grafana dashboards, OpenTelemetry tracing, and managed versions on GKE and AKS

Watch out for

  • Many moving parts and resource types to learn; debugging means understanding Envoy configuration as well as Kubernetes
  • Sidecar mode adds a proxy’s CPU and memory to every pod and requires pod restarts on each Istio upgrade
  • Built around Kubernetes: each release supports only a range of Kubernetes versions (1.28 to 1.31 for 1.24), so mesh and cluster upgrades have to be planned together
  • Ambient mode is newer: some managed offerings, such as the AKS add-on, support only sidecars

Alternatives

What all service discovery & mesh have in common →
EnvoyOpen sourceA C++ proxy for the edge and between services, configured live through the xDS APIs; the data plane under Istio, Envoy Gateway, Consul’s mesh and many others.HashiCorp ConsulCommercialA service registry with health checks and a DNS interface, plus a service mesh that configures Envoy proxies for mTLS between services.

How it fits with other technologies

Require mTLS mesh-wide and send 10% of traffic to a new version · yaml

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata: { name: default, namespace: istio-system }
spec:
  mtls: { mode: STRICT }        # refuse plain-text traffic between workloads
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata: { name: reviews }
spec:
  host: reviews
  subsets:
    - { name: v1, labels: { version: v1 } }
    - { name: v2, labels: { version: v2 } }
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata: { name: reviews }
spec:
  hosts: [reviews]
  http:
    - retries: { attempts: 3, perTryTimeout: 2s }
      route:
        - { destination: { host: reviews, subset: v1 }, weight: 90 }
        - { destination: { host: reviews, subset: v2 }, weight: 10 }

See it in a real stack

No architecture uses Istio yet. Drop it into the playground and wire it up yourself.Open playground →

Worth exploring

Article· February 2021Alternative to AWS lambda serverless concept in Kubernetes?Stack Overflow question by ajsgA team running everything on Kubernetes asks how to get Lambda-style, per-request scaling for loading AI models from S3. The 2021 answers name Knative, KFServing (now KServe) and Kubeless (since archived), which makes it a quick snapshot of the options rather than an up-to-date guide.
All resources →
Where it came from2017–2024

As companies split applications into microservices, every team had to solve service discovery, load balancing, retries, monitoring and security again, often with libraries that differed by language. Standardising on one RPC library such as gRPC was costly and left out older applications that couldn’t be changed. Lyft had built Envoy for this and ran it for over a year in front of more than 100 services, while Google and IBM had used the proxy-per-service pattern internally for years.

On May 24, 2017, Google, IBM and Lyft announced Istio 0.1: a control plane that injects Envoy next to every service on Kubernetes and gives operators traffic control, telemetry and mutual TLS without changing application code. Version 1.0 followed in July 2018. The control plane itself began as separate microservices (Pilot, Galley, Citadel and Mixer), which most users installed and ran as one unit anyway, so Istio 1.5 merged them into a single binary, istiod, in March 2020.

Users kept reporting that sidecars were expensive and disruptive: a proxy in every pod, applications broken by injection, and restarts with every upgrade. In September 2022 the project announced ambient mesh, joined the CNCF as an incubating project that month, and graduated in July 2023. Ambient mode became generally available in November 2024 with Istio 1.24.

Why it’s built this way

Proxies injected next to apps instead of a library in each
A proxy works with any language and with brownfield apps that can’t be changed, and it gives operators one place to apply routing, security and telemetry. Lyft’s production experience with Envoy showed it could carry the load.
One istiod binary instead of control-plane microservices
Splitting Pilot, Galley, Citadel and Mixer brought the costs of microservices without the benefits, since one team ran them all. Merging them in 1.5 made Istio simpler to install, upgrade and debug.
Split Layer 4 from Layer 7 in ambient mode
Most users wanted mTLS, authorization and telemetry first. A shared per-node proxy gives that cheaply, and Layer 7 waypoints are added only where routing or rich policy is needed, so a mesh can be adopted one namespace at a time.
Write ztunnel in Rust instead of reusing Envoy
Ambient’s node proxy first ran on Envoy, but its narrow job of tunnelling many workloads’ connections fit Envoy poorly. Prototypes in Go and Rust followed, and the team chose Rust for speed, safety and a small footprint.

Timeline

  1. 2017

    Google, IBM and Lyft announce Istio 0.1 in May

  2. 2018

    Istio 1.0, ready for production, in July

  3. 2020

    Istio 1.5 merges the control plane into istiod

  4. 2022

    Ambient mesh announced; Istio joins the CNCF as an incubating project in September

  5. 2023

    Graduates from the CNCF in July; Rust-based ztunnel introduced

  6. 2024

    Ambient mode becomes generally available in Istio 1.24 in November

Sources17 · facts checked 6 October 2026

Improve this page on GitHub