Service Mesh: Istio, Envoy & mTLS
A service mesh moves cross-cutting networking concerns (mTLS, retries, circuit breaking, traffic shifting, observability) out of application code and into an infrastructure layer. Istio is the most wi
A service mesh moves cross-cutting networking concerns (mTLS, retries, circuit breaking, traffic shifting, observability) out of application code and into an infrastructure layer. Istio is the most widely deployed service mesh. It injects an Envoy sidecar proxy into every Pod; all traffic between Pods flows through these proxies, which are centrally configured by the Istio control plane (istiod). Applications speak plain HTTP/gRPC; mTLS and L7 policies are applied transparently by the proxy layer.
-
Istiod (the Istio control plane) runs as a Deployment and comprises three merged components: Pilot (service discovery and traffic config), Citadel (certificate management for mTLS), and Galley (config validation).
-
Envoy sidecar proxies are injected automatically into Pods in namespaces labeled istio-injection: enabled. Each proxy intercepts all inbound and outbound traffic for its Pod.
-
mTLS: every proxy presents a workload-specific certificate (issued by Istio's CA) when establishing connections. Traffic between mesh Pods is encrypted and mutually authenticated at the proxy layer -- no application code changes needed.
-
VirtualService defines routing rules (e.g., 90% traffic to v1, 10% to v2). DestinationRule defines load balancing, connection pool settings, and outlier detection (circuit breaking) per destination.
-
PeerAuthentication enables mTLS per namespace or workload. AuthorizationPolicy defines which workloads can communicate with which others at L7.
-
Label namespace with istio-injection: enabled.
-
istiod injects Envoy sidecar containers into new Pods in that namespace.
-
istiod issues workload-specific X.509 certificates to each Envoy sidecar.
-
All traffic between Pods flows through Envoy proxies; mTLS established at proxy layer.
-
VirtualService and DestinationRule objects configure routing, retries, timeouts, and circuit breaking.
-
PeerAuthentication and AuthorizationPolicy objects enforce mTLS and L7 access control.
-
Prometheus scrapes Envoy metrics (latency, error rate, traffic) from all sidecar proxies automatically.
-
Zero-trust security: mTLS and AuthorizationPolicy enforce that only authorized workloads can communicate.
-
Canary traffic splitting at L7 without application code changes using VirtualService weight rules.
-
Automatic retry and circuit breaking for all inter-service calls, configured centrally.
-
Complete per-service L7 observability (latency P99, error rate, traffic volume) with no instrumentation code.
-
Start with permissive mTLS mode, then move to STRICT after verifying all services are in the mesh.
-
Use AuthorizationPolicy to explicitly allow only the service-to-service communication that should exist.
-
Monitor istiod resource usage -- it is a critical control plane component.
-
Use istioctl analyze before applying new VirtualService and DestinationRule objects.
-
Enabling sidecar injection without resource requests/limits on the sidecar -- it competes with the application.
-
Not accounting for the sidecar startup time in Pod readiness -- the init container iptables rules change traffic flow immediately.
-
Confusing Kubernetes NetworkPolicy (L3/L4) with Istio AuthorizationPolicy (L7) -- both can coexist but control different things.
-
Setting mTLS to STRICT before all services are enrolled in the mesh -- breaks plaintext communication from non-mesh clients.
-
Right-size Envoy sidecar CPU/memory requests -- multiply by total Pod count for cluster-wide impact.
-
Use Istio's ambient mesh mode (alpha/beta) to eliminate per-Pod sidecar overhead where sidecar is too costly.
-
Run istiod with multiple replicas and resource limits as a production-critical component.
-
Keep Istio version current -- security patches and performance improvements are released frequently.
-
Gradually onboard namespaces to the mesh rather than enabling cluster-wide injection all at once.
-
Install Istio on a test cluster and enable sidecar injection on a namespace; verify traffic between two services uses mTLS.
-
Configure a VirtualService with 90/10 traffic split and verify the approximate split in Prometheus metrics.
-
Apply a STRICT PeerAuthentication policy and verify that non-mesh clients can no longer connect.
-
A service mesh moves mTLS, retries, circuit breaking, and L7 observability out of application code into an infrastructure layer.
-
Istio's data plane is all Envoy sidecars; the control plane is istiod (Pilot + Citadel + Galley merged).
-
mTLS is transparent to applications -- Envoy handles encryption and mutual authentication at the proxy layer.
-
VirtualService defines routing rules; DestinationRule defines per-destination behavior (load balancing, circuit breaking).
-
PeerAuthentication enforces mTLS policy; AuthorizationPolicy enforces L7 workload-to-workload access control.
Want a visual for this concept?
Generate a diagram tailored to “Service Mesh: Istio, Envoy & mTLS” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →