How Istio Works

Istio is usually described as having two planes:

• Control plane - configures and manages the mesh.
• Data plane - handles the actual network traffic for workloads.

Control Plane

The main Istio control plane component is istiod. It watches Kubernetes and Istio configuration, then distributes the required proxy configuration to the mesh data plane.

istiod is responsible for:

• Discovering services and endpoints
• Translating Istio resources into proxy configuration
• Distributing certificates and identity information
• Pushing traffic, security, and telemetry configuration to the data plane

Data Plane

The data plane is where application traffic is intercepted and controlled. Traditionally, Istio used an Envoy sidecar proxy next to every application pod. Newer Istio releases also support ambient mesh, which reduces or removes the need for sidecars for some scenarios.

Sidecar Mode

In sidecar mode, each application pod gets an Envoy proxy injected into it. Application traffic flows through the proxy before leaving or entering the pod.

Sidecar mode provides mature and granular control, including:

• Per-workload traffic policy
• mTLS between workloads
• Advanced routing
• Detailed telemetry

The trade-off is that each pod has an extra container. This has resource, lifecycle, and troubleshooting implications.

Ambient Mode

Ambient mesh is a newer Istio data plane mode designed to reduce sidecar overhead. Instead of injecting an Envoy sidecar into every pod, ambient mode uses node-level and optional waypoint proxies to provide mesh features.

Ambient mode is designed to make adoption easier by separating:

• Secure connectivity - transparent mTLS and identity at the node level
• Layer 7 policy - optional waypoint proxies for HTTP-aware routing and policy

Ambient mode can reduce operational friction, but it is newer than sidecar mode and feature support may differ depending on the Istio and platform version.

Istio Gateways

An Istio gateway manages traffic entering or leaving the mesh. It is conceptually similar to an ingress controller, but it is integrated with Istio traffic policy.

For ingress, an Istio gateway commonly works with:

• A Kubernetes Service of type LoadBalancer
• An Istio Gateway resource that defines ports, hosts, and protocols
• An Istio VirtualService that defines where matching traffic should go

This lets you apply routing rules at the edge, such as:

• Route /api to one service and /web to another
• Split traffic between two versions of a service
• Match traffic based on headers
• Terminate TLS at the gateway

Key Istio Resources