Stage 4 · Provision
Load Balancing & Traffic Management
Service Mesh Traffic Control
Istio and Linkerd for mTLS, retries, timeouts, and circuit breaking between services.
What Is a Service Mesh?
A service mesh is an infrastructure layer that handles service-to-service communication. It moves networking concerns — retries, timeouts, circuit breaking, mTLS — out of application code and into the infrastructure. Every service gets a sidecar proxy that intercepts all network traffic.
The Data Plane
The data plane consists of lightweight proxies (Envoy or linkerd2-proxy) deployed as sidecars alongside each service. Every inbound and outbound network request passes through the sidecar, which handles load balancing, retries, timeouts, and encryption transparently.
┌──────────────────────────────┐
│ Pod │
│ ┌──────────┐ ┌───────────┐ │
│ │ App │◄►│ Sidecar │ │
│ │ Container│ │ (Envoy) │ │
│ └──────────┘ └─────┬─────┘ │
│ │ │
└──────────────────────┼───────┘
│
mTLS connection
│
┌──────────────────────┼───────┐
│ ┌──────────┐ ┌─────┴─────┐ │
│ │ Sidecar │◄►│ App │ │
│ │ (Envoy) │ │ Container │ │
│ └──────────┘ └───────────┘ │
│ Pod │
└──────────────────────────────┘The app communicates with localhost. The sidecar handles all external communication. The app never knows about mTLS, retries, or circuit breaking — it just sends HTTP requests to localhost.
The Control Plane
The control plane (Istiod, Linkerd control plane) distributes configuration to all sidecars. It handles service discovery, certificate issuance, traffic routing rules, and telemetry collection. Sidecars never talk to each other directly for configuration.
Mutual TLS
Service mesh provides automatic mTLS between all services without code changes. Every service gets a certificate from the control plane. Connections are encrypted and authenticated. This eliminates the need for manual certificate management.
Without mTLS, any pod on the cluster can impersonate any other service. Service mesh enforces identity at the network layer. In production, always enable strict mTLS mode.
Traffic Policies
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: payment-service
spec:
host: payment-service
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
h2UpgradePolicy: DEFAULT
http1MaxPendingRequests: 50
http2MaxRequests: 100
loadBalancer:
simple: LEAST_REQUEST
outlierDetection:
consecutive5xxErrors: 3
interval: 10s
baseEjectionTime: 30s
maxEjectionPercent: 50This policy sets connection limits, load balancing strategy, and automatic ejection of unhealthy hosts. If a backend returns 3 consecutive 5xx errors, it is ejected for 30 seconds.
Built-in Observability
Service mesh automatically generates metrics, access logs, and distributed traces for every request. This gives you visibility into service-to-service communication without instrumenting application code.
- Metrics: request count, latency, error rate, connection pool usage per service pair.
- Traces: full distributed trace for every request through the mesh.
- Access logs: detailed request/response logs for debugging.
- Dashboards: Kiali provides a visual service graph with real-time traffic data.
Istio is powerful but complex. Linkerd is lighter, easier to operate, and provides 80% of the functionality. Start with Linkerd unless you need Istio-specific features like WasmExtensibility or advanced traffic management.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.