Control Plane

Kubernetes hub

The central management component of a service mesh that distributes configuration to all sidecar proxies. In Istio, the control plane is called istiod. It manages certificate issuance, routing rule distribution, and service discovery - but never handles actual service traffic.

What is the Control Plane

A service mesh has two distinct parts. The control plane is the brain. The data plane is the muscle.

TEXT

Control Plane (istiod in Istio):
  - Watches Kubernetes for Service, Endpoint, and mesh resource changes
  - Calculates routing configuration for each sidecar
  - Pushes configuration to sidecars via xDS protocol
  - Issues and rotates mTLS certificates (built-in CA)
  - NEVER sees or handles actual service traffic
 
Data Plane (all Envoy sidecars):
  - Handles actual inbound and outbound traffic for each pod
  - Enforces mTLS, applies routing rules, collects metrics
  - Receives configuration from control plane
  - DOES handle actual service traffic
 
The control plane pushes config.
The data plane executes it.

istiod - Istio's Control Plane

In older versions of Istio, the control plane was split into multiple components (Pilot, Citadel, Galley). Modern Istio consolidates all of this into a single process: istiod.

Bash

## Check the control plane is running
kubectl get pods -n istio-system
 
## Expected:
## istiod-abc123    1/1    Running   0

istiod handles three responsibilities:

TEXT

1. Traffic management:
   Watches VirtualService and DestinationRule resources
   Translates them into Envoy xDS configuration
   Pushes to all affected sidecars
 
2. Security (Citadel role):
   Runs as a Certificate Authority (CA)
   Issues SVID certificates to pods based on Service Account
   Rotates certificates every 24 hours automatically
 
3. Configuration validation (Galley role):
   Validates Istio resource correctness
   Rejects misconfigured VirtualServices before they are applied

Control Plane Resilience

The control plane is critical for configuration distribution but NOT for data plane availability. If istiod goes down:

TEXT

Existing sidecars continue working with their last configuration
New routing rules cannot be pushed
Certificate rotation stops (certificates eventually expire after 24h)
New pods cannot join the mesh (no certificates issued)

This means a brief istiod outage does not immediately break your services - but it must be restored before certificates expire.

Sidecar-Control Plane Communication

Bash

## Check sync status between all sidecars and the control plane
istioctl proxy-status
 
## Output shows per-pod sync state:
## SYNCED  = sidecar has the latest config
## STALE   = sidecar has outdated config (network issue or lag)
## NOT SENT = control plane has not sent config to this sidecar yet

Remember
The control plane never sees your actual service traffic. It only pushes configuration. All request handling, mTLS termination, metric collection, and routing decisions happen in the data plane sidecars. If the control plane goes down, existing traffic continues flowing normally.

Tip
Run the control plane with at least 2 replicas in production. A single istiod pod is a single point of failure for configuration distribution and certificate rotation. kubectl scale deployment istiod -n istio-system --replicas=2

Frequently Asked Questions

Why does a service mesh control plane never touch actual service traffic?

The control plane's job is distributing configuration — routing rules, mTLS certificates, service discovery data — to the sidecar proxies (like Envoy) that sit next to each application container. Those sidecars, collectively called the data plane, are what actually intercepts and forwards every request. Separating the two means the control plane (istiod, for example) can be updated, scaled, or briefly unavailable without interrupting live traffic, since proxies keep operating on their last-received configuration.

What's a common mesh control plane gotcha in production?

Assuming a control plane outage means traffic stops — it doesn't, because sidecars cache the last configuration they received and keep routing based on it. The real risk is configuration going stale: if the control plane is down while services scale or endpoints change, sidecars won't learn about new instances, causing requests to route to pods that no longer exist or miss newly added ones, which looks like intermittent errors rather than an obvious outage.