Istio

Istio is the most widely deployed service mesh for Kubernetes. It moves cross-cutting networking concerns — encryption between services, service identity and authorization, retries and timeouts, traffic splitting for canaries, and uniform telemetry — out of application code and into infrastructure. A control plane, istiod, configures a data plane of Envoy-based proxies that handle every request between services.

Istio is powerful and correspondingly complex. It now offers two data plane modes: the classic sidecar mode, with an Envoy proxy in every pod, and ambient mode, which provides mutual TLS and L4 policy through a per-node ztunnel and adds L7 features only where needed through waypoint proxies. Choosing the mode and adopting features gradually is the key to running Istio successfully.

TL;DR

Quick Example

Require mTLS mesh-wide, allow only the checkout service to create orders, and send 10% of order traffic to a new version:

Enroll a namespace in ambient mode, or in sidecar mode, with a label:

Core Concepts

Architecture

Sidecar Versus Ambient

Ambient mode suits teams that mainly want mTLS and identity-based policy, adding L7 features selectively. Sidecar mode remains appropriate where every service needs L7 behavior or specific Envoy extensions.

Security

istiod issues each workload a short-lived certificate tied to its Kubernetes service account. Proxies use them for mutual TLS, so every connection is encrypted and both sides are authenticated. PeerAuthentication controls whether plaintext is still accepted (useful during migration). AuthorizationPolicy then expresses who may call what — the building block for zero trust between services.

Traffic Management

Telemetry

Proxies emit request metrics (rate, errors, duration), access logs, and trace spans for every call, giving uniform observability across services regardless of language. Applications still need to propagate trace headers to keep traces connected. See OpenTelemetry.

Operating Istio

Best Practices

Adopt Features Incrementally

Start with mTLS and telemetry, then authorization, then traffic management. Enabling everything at once makes failures hard to attribute.

Migrate to STRICT mTLS Deliberately

Run in permissive mode while enrolling workloads, confirm all traffic is mTLS through telemetry, then switch to STRICT namespace by namespace.

Prefer the Gateway API

Use Gateway and HTTPRoute for new routing configuration; it is portable across implementations and is where Kubernetes networking is heading.

Keep Application Timeouts Aligned

Mesh retries multiplied by application retries can amplify load during incidents. Set retry budgets and timeouts consistently across both layers.

Common Mistakes

Turning On Retries Everywhere

Authorization Policies Without a Plan

Upgrading istiod In Place

FAQ

What is Istio used for?

Securing, connecting, and observing services in Kubernetes: automatic mutual TLS, identity-based authorization, traffic routing for canaries and failover, resilience features such as retries and outlier detection, and consistent metrics, logs, and traces.

What is Istio ambient mode?

A sidecar-less data plane. A per-node ztunnel proxy handles mTLS, identity, and L4 policy for all pods in enrolled namespaces, and optional waypoint proxies add L7 features. It reduces resource overhead and avoids restarting pods to adopt the mesh.

Do I need a service mesh?

Not always. Meshes help most with many services across teams that need uniform mTLS, policy, and telemetry. Small systems can often meet their needs with network policies, ingress controllers, and libraries.

Istio or Linkerd?

Istio offers the broadest feature set and two data plane modes. Linkerd focuses on simplicity, low overhead, and secure defaults with a smaller feature set. See Linkerd and Service Mesh.

Does Istio support the Kubernetes Gateway API?

Yes. Istio implements the Gateway API for ingress and for mesh traffic, and recommends it for new configuration.

Related Topics

References