Service Mesh — Advanced Operations

In a service mesh: the data plane handles actual network traffic (the sidecar proxies — Envoy in Istio — intercept and route requests). The control plane manages configuration distribution and service discovery, pushing routing rules, policies, and certificates to the data plane.

"Istio's architecture: istiod (control plane) distributes xDS configuration to Envoy sidecars (data plane). When you apply a VirtualService YAML, istiod translates it to Envoy Listener/Cluster/Route config and pushes it to relevant sidecars via gRPC streaming. Traffic never passes through istiod — only configuration does."

A proxy container (Envoy) injected alongside each application pod in an Istio service mesh. Intercepts all inbound and outbound network traffic via iptables rules. Handles: traffic encryption (mTLS), load balancing, circuit breaking, retries, timeouts, observability (metrics, traces).

"When sidecar injection is enabled for a namespace, Istio's webhook automatically adds an Envoy container to every pod. The app container has no network code — it talks to localhost as normal. Envoy intercepts all traffic, applies policies (mTLS, retries), emits metrics, and propagates trace context headers. Zero application code changes required."

An Istio resource that defines traffic routing rules for a service. Routes traffic based on headers, URI, method, weights. Enables: canary releases (90% to v1, 10% to v2), A/B testing (route by header), fault injection (inject delays or errors for testing).

"Our canary VirtualService routes: traffic with header 'x-canary: true' goes to checkout-v2, all other traffic to checkout-v1. After a week, we change weights: 90% to checkout-v1, 10% to checkout-v2 (no header required). After another week: 0% v1, 100% v2. The transition is config-only — no redeploy, no DNS change."

An Istio resource defining policies for traffic after it's been routed. Defines subsets (v1, v2 based on labels), load balancing settings, circuit breaker (outlier detection), connection pool limits, and TLS settings for the destination.

"The DestinationRule for payments-service defines: subset v1 (pod label version: v1), subset v2 (version: v2), outlier detection (eject a pod after 5 consecutive 5xx errors for 30 seconds), connection pool (max 100 connections per pod). Combined with the VirtualService, this gives precise traffic shaping and resilience without application code changes."

Mutual TLS requires both parties in a connection to authenticate with certificates. In Istio, SPIFFE-based workload identities are automatically provisioned; Envoy sidecars handle the TLS negotiation. Enables zero-trust service-to-service communication without application changes.

"With Istio's PeerAuthentication set to STRICT mode, all inter-service communication requires mTLS. Envoy sidecars handle cert negotiation transparently — the application code uses plain HTTP internally. If a rogue container tries to talk to the payments service without a valid certificate, the connection is rejected at the sidecar level."

Istio's sidecar-less architecture mode. Instead of per-pod Envoy sidecars, a node-level ztunnel (zero-trust tunnel) handles L4 security (mTLS, authorisation). L7 features (retries, traffic shaping) use waypoint proxies per namespace or service — only deployed when needed.

"We're evaluating ambient mode for our high-density microservices cluster. With sidecars, 40% of pods are Envoy containers. Ambient mode replaces per-pod sidecars with one ztunnel per node — significant resource reduction. The caveat: L7 policies require deploying waypoint proxies, adding some complexity for services needing traffic shaping."

A testing technique in a service mesh where artificial delays or HTTP errors are injected into traffic between services — without modifying application code. Used to verify resilience: does the upstream service handle downstream timeouts and errors gracefully?

"We used Istio fault injection to test our cart service's resilience. VirtualService config: inject 500ms delay for 50% of requests to inventory-service. Test result: cart service timed out and returned 503 — we found a missing fallback. After adding a cache-based fallback, we re-ran fault injection: cart returned cached inventory data during the 500ms delay."