Skip to main content
In this lesson we’ll explore Istio: what it is, how it works, its architecture, and the components that make it a powerful service mesh for cloud-native applications. Istio is an open-source service mesh that provides a consistent way to secure, connect, and observe microservices. It injects traffic management, telemetry, and security features into applications without requiring changes to application code. Istio works natively with Kubernetes and can also manage VM-based workloads, giving you a unified control plane across heterogeneous environments. Key benefits:
  • Centralized traffic management (routing, retries, circuit breaking)
  • Strong security with mutual TLS and certificate rotation
  • Rich telemetry and observability (metrics, traces, logs)
  • Policy enforcement (rate limits, authorization)

​
High-level architecture

Istio splits responsibilities into two primary planes:
  • Data plane — composed of lightweight proxies (Envoy) deployed as sidecars next to each service instance. These sidecars intercept network traffic, perform routing and load balancing, collect telemetry, and enforce security policies for the application.
  • Control plane — a centralized management layer that configures and manages the proxies, distributes policies and certificates, and performs service discovery and validation.
This separation enables Istio to introduce advanced networking and security features without changes to application code.

​
Envoy sidecar (data plane)

Istio uses the high-performance Envoy proxy for the data plane. Each workload typically has an Envoy sidecar that intercepts inbound and outbound network traffic and applies policies defined by the control plane. Responsibilities of Envoy sidecars:
  • Traffic routing and load balancing
  • Request/response transformations and header manipulation
  • Observability: emitting metrics, distributed traces, and logs
  • Enforcing mutual TLS and authorization policies

​
Control plane (istiod)

Historically, Istio’s control plane consisted of several components:
  • Pilot — service discovery and routing configuration
  • Citadel — certificate issuance and key management
  • Galley — configuration validation and distribution
These components have been consolidated into a single binary/daemon called istiod. Istiod performs control-plane functions such as:
  • Distributing configuration to Envoy proxies using xDS APIs
  • Issuing and rotating certificates for mutual TLS
  • Validating and reconciling configuration resources

​
Istio agent

Each pod or VM workload typically runs a small local helper process called the Istio agent. The agent handles:
  • Obtaining and rotating workload certificates
  • Delivering secrets and configuration to the Envoy sidecar (for example, via SDS and xDS)
  • Managing local bookkeeping (e.g., proxy bootstrap files, logs)
This local agent plus the central istiod allows Istio to manage certificate lifecycle and secure communication between services.
A diagram of an Istio service-mesh architecture showing a Control Plane (Istiod, Citadel, Pilot, Galley) above a Data Plane. The Data Plane shows multiple microservice pods (Product Page, Details, Reviews, Ratings) each with an Istio agent and Envoy sidecar, using different runtimes (Python, Ruby, Java, Node).
Istio’s control plane (istiod) exposes configuration to Envoy proxies using the xDS APIs. The local Istio agent handles certificate lifecycle and secret delivery to Envoy (typically via SDS). This separation enables features such as traffic routing, mutual TLS, and automatic telemetry without modifying application code.

​
Istio components at a glance

​
How Istio works (flow summary)

  1. Developers define application networking and security policies using Istio CRDs such as VirtualService and DestinationRule.
  2. istiod validates and converts those policies into xDS configuration.
  3. Envoy sidecars fetch configuration from istiod and receive certificates/secrets from the Istio agent (SDS).
  4. Envoy enforces routing, load balancing, retries, and security policies; it also emits telemetry to backends (Prometheus, Jaeger).
  5. istiod continuously reconciles cluster state and updates Envoy via xDS as the system changes.

​
Example commands

Install Istio (simplified):
Inject a sidecar into a namespace:
Inspect Envoy config for a specific pod:

​
Use cases

  • Secure service-to-service communication with mutual TLS
  • Fine-grained traffic control for canary releases and A/B testing
  • Centralized observability (distributed tracing, metrics, logs)
  • Policy enforcement for rate limiting and access control
For further reading, consult the Istio documentation for deep dives into configuration primitives (VirtualService, DestinationRule, Gateway) and advanced features like multi-cluster and ingress/egress gateway setups.

Watch Video