Data Plane

Kubernetes hub

All the sidecar proxy instances running alongside application pods in a service mesh. The data plane handles actual service traffic - applying mTLS, routing rules, retries, and metrics collection on every request.

What is the Data Plane

In a service mesh, the data plane is all the sidecar proxies running alongside your pods. If you have 50 pods in your cluster, you have 50 sidecar proxies - this collection of proxies is the data plane.

TEXT

Data Plane = all sidecars running in the cluster
(Envoy instances in Istio, Rust proxy instances in Linkerd)
 
Every single request that flows between services passes through the data plane.
No request bypasses the sidecar proxies.

Data Plane vs Control Plane

The most important distinction in service mesh architecture:

◈ DIAGRAM

Control Plane (istiod):
  PUSHES configuration to sidecars
  NEVER handles service traffic
  If it goes down → config cannot update, but traffic continues
 
Data Plane (all sidecars):
  HANDLES actual service traffic
  ENFORCES the configuration it received from control plane
  If one sidecar goes down → only that pod is affected
 
Think of it like this:
Control plane = air traffic controller (gives instructions, never flies)
Data plane = the aircraft (actually moves the traffic)

What the Data Plane Does on Every Request

For every inbound request to a pod:

TEXT

1. Sidecar intercepts the incoming connection (via iptables)
2. Validates the mTLS client certificate from the caller's sidecar
3. Decrypts the encrypted connection
4. Applies any inbound authorization policy
5. Delivers plain HTTP to the application
6. Records: start time, source service, destination, request metadata

For every outbound request from a pod:

TEXT

1. Sidecar intercepts the outgoing connection
2. Looks up the routing rules from the control plane config
3. Applies traffic splitting weights if a VirtualService matches
4. Initiates mTLS with the target service's sidecar
5. Records: response code, response time, bytes transferred

Data Plane Resource Consumption

Each sidecar proxy consumes real resources on every node:

TEXT

Envoy (Istio):  ~50-100 MB memory, ~0.1-0.5 vCPU per sidecar
Linkerd proxy:  ~10-20 MB memory, ~0.05 vCPU per sidecar
 
100 pods with Istio: 5-10 GB additional memory cluster-wide
100 pods with Linkerd: ~1-2 GB additional memory cluster-wide

This is why resource budgeting is critical before installing a service mesh.

Checking Data Plane Health

Bash

## See all sidecar proxies and their sync status with control plane
istioctl proxy-status
 
## Check a specific pod's proxy configuration
istioctl proxy-config cluster \
  $(kubectl get pod -l app=orders -n production \
    -o jsonpath='{.items[0].metadata.name}').production
 
## View a proxy's full Envoy config (advanced debugging)
istioctl proxy-config all \
  orders-pod-abc123.production -o json

Remember
The data plane is what actually makes the service mesh work for your applications. The control plane is just the configuration distribution system. When engineers say "the mesh is handling mTLS" or "the mesh is applying circuit breaking" - that work is happening in the data plane sidecars, not in istiod.

Tip
Monitor data plane resource usage per node, not just per pod. A node running 20 pods with Envoy sidecars has 20 × 100MB = 2 GB consumed just by mesh proxies. Factor this into your node sizing before installing Istio on a production cluster.

Frequently Asked Questions

How is the data plane different from the control plane in a service mesh?

The control plane (e.g. Istio's istiod) is the brain — it compiles routing rules, certificates, and policies and pushes configuration out. The data plane is where that configuration actually executes: dozens or hundreds of Envoy sidecars, one per pod, intercepting every inbound and outbound request. If the control plane goes down temporarily, the data plane keeps running on its last-known config, since proxies cache configuration locally rather than calling home per-request.

What's the main production cost of running a sidecar-based data plane?

Every request now hops through two extra proxies (client sidecar, then server sidecar), adding latency — typically single-digit milliseconds per hop, but it adds up in deep call chains — plus real CPU and memory overhead per pod, often the biggest line item people underestimate when sizing a mesh rollout. This is why newer 'sidecar-less' architectures like Istio's ambient mode move some of this work to shared per-node proxies instead of one-per-pod.