Skip to main content

Istio Ambient Mode Architecture

This section describes how Istio implements a service mesh in practice, at a high level. You do not need to understand Kubernetes internals to use this guide.

The goal is to explain which Istio components are involved in traffic flow, so you can reason about where a problem might be occurring.

Istio vs Kubernetes Networking​

This is different from the Kubernetes networking layer, which is responsible for:

  • Pod networking
  • Service IPs and load balancing
  • DNS
  • Node-to-node connectivity

Kubernetes networking decides whether traffic can flow at all. Istio decides what happens to traffic once it is flowing.

Because of this separation, many connectivity issues that look like Istio problems are actually caused by:

  • Application misconfiguration
  • Kubernetes Services or selectors
  • DNS issues
  • Node or CNI networking problems

What Istio Ambient Mode Changes​

In ambient mode, Istio changes how network traffic is intercepted and processed, without modifying application pods.

At a high level:

  • All service‑to‑service traffic passes through Istio‑managed infrastructure
  • Traffic can be secured, allowed, denied, or routed based on configuration
  • HTTP‑level inspection only happens if you explicitly enable HTTP routing or policies

Application containers:

  • Are not modified
  • Do not run sidecars
  • Start and stop exactly as they would without Istio

The Main Istio Components​

Istio ambient mode is implemented using a small number of background components:

istiod (control plane)

  • Stores and distributes Istio configuration
  • Provides identity and policy information to the data plane

ztunnel (runs on every node)

  • Intercepts service‑to‑service traffic
  • Handles encryption and basic allow/deny behavior
  • Must be running on every node for ambient mode to function

Waypoint proxies (only when using HTTP features)

  • Handle HTTP routing and HTTP‑level policies
  • Required for resources such as:
    • HTTPRoute
    • HTTP‑level AuthorizationPolicy

Gateways

  • Handle traffic entering or leaving the cluster
  • Are normal Kubernetes workloads managed by Istio

What Istio Does Not Do​

Istio ambient mode does not replace Kubernetes networking or application configuration.

It does not:

  • Start, stop, or restart application pods
  • Decide whether a pod is healthy
  • Create Services or endpoints
  • Fix DNS or node‑level networking

If traffic is failing because:

  • Pods are not ready
  • Services have no endpoints
  • DNS does not resolve

then the issue is outside of Istio, even if Istio is installed.

How Traffic Flows (Conceptual)​

You do not need to memorize this, but it helps explain which Istio components are involved.

Service → Service (no HTTP routing or policies)

Service → ztunnel → ztunnel → Service

Service → Service (with HTTP routing or policies)

Service → ztunnel → waypoint → ztunnel → Service

External Traffic

Client → Gateway → ztunnel → (waypoint, if used) → Service

If traffic never reaches your service, identifying which part of this path is involved helps narrow down the cause.

Istio Component Dependency Chain​

Istio ambient mode components depend on each other in this order:

istiod
  ↓
ztunnel (runs on every node)
  ↓
waypoint proxies (if used)
  ↓
gateways

If a component earlier in the chain is unhealthy, everything below it may fail.