5 exercises on service mesh — data plane, control plane, mTLS, traffic policy, and Envoy.
0 / 5 completed
1 / 5
What is the data plane in a service mesh?
Data plane: the sidecar proxies intercept all inbound and outbound traffic. They enforce mTLS, apply retries and circuit breaking, and emit telemetry. They act on the policies distributed by the control plane without the application being aware.
2 / 5
What does the control plane do in a service mesh like Istio?
Control plane (Istiod): it discovers services, generates Envoy xDS configurations (routes, clusters, listeners), distributes mTLS certificates from its CA, and propagates traffic policies. Proxies receive configuration via the xDS API and apply it to live traffic.
3 / 5
What is mTLS (mutual TLS) in a service mesh?
mTLS: each service gets a SPIFFE/X.509 identity certificate issued by the mesh CA. When service A calls B, both present certificates — A proves its identity to B and B proves its identity to A. This prevents impersonation and encrypts lateral traffic without application code changes.
4 / 5
What is traffic policy in a service mesh?
Traffic policy: Istio's VirtualService defines fine-grained routing (send 10% of traffic to v2), while DestinationRule defines load balancing and connection pool settings. This enables progressive delivery and chaos engineering (fault injection) without application-level changes.
5 / 5
What is Envoy and why is it central to service meshes?
Envoy: written in C++, it supports HTTP/1.1, HTTP/2, gRPC, and TCP with rich observability (stats, tracing). Its xDS API allows dynamic configuration without restarts. The combination of Envoy's power and xDS made it the de-facto data plane for service meshes.