Stage 3 · Build
Load Balancing & Traffic Management
Service Mesh Traffic Control
Istio/Linkerd traffic policies, retries, circuit breakers, and canary splits.
What a Service Mesh Does
A service mesh adds a proxy (sidecar) to every pod in the cluster. The proxy intercepts all network traffic and provides load balancing, retries, circuit breaking, mTLS, and observability without changing application code. Istio, Linkerd, and Cilium are the most common meshes.
Without mesh:
[App Container] -> [Network] -> [App Container]
With mesh (sidecar):
[App Container] -> [Envoy Proxy] -> [Network] -> [Envoy Proxy] -> [App Container]
(localhost) (sidecar) (sidecar) (localhost)The sidecar proxy intercepts all inbound and outbound traffic. The application connects to localhost, and the proxy handles routing, retries, encryption, and metrics. This is transparent to the application.
Traffic Policies
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: api-service
spec:
host: api-service
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
h2UpgradePolicy: DEFAULT
maxRequestsPerConnection: 10
loadBalancer:
simple: LEAST_REQUEST
outlierDetection:
consecutive5xxErrors: 5
interval: 30s
baseEjectionTime: 30s
maxEjectionPercent: 50outlierDetection is Istio's circuit breaking. If a server returns 5xx errors 5 times in 30 seconds, it is ejected from the pool for 30 seconds. maxEjectionPercent prevents all servers from being ejected simultaneously.
Retries and Timeouts
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: api-service
spec:
hosts:
- api-service
http:
- route:
- destination:
host: api-service
timeout: 10s
retries:
attempts: 3
perTryTimeout: 3s
retryOn: gateway-error,connect-failure,refused-streamtimeout is the total time budget for the request. retries.attempts is how many retries to attempt. perTryTimeout is the timeout for each individual attempt. The total time budget includes retries — 3 attempts with 3s perTryTimeout within a 10s timeout.
Retries amplify traffic. If 10% of requests fail and you retry 3 times, you add 30% more traffic to a failing service. Use retry budgets (maxRetries in Linkerd) or circuit breakers to prevent retry storms.
Canary Deployments
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: api-service
spec:
hosts:
- api-service
http:
- route:
- destination:
host: api-service
subset: stable
weight: 90
- destination:
host: api-service
subset: canary
weight: 10
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: api-service
spec:
host: api-service
subsets:
- name: stable
labels:
version: v1
- name: canary
labels:
version: v290% of traffic goes to the stable version, 10% goes to the canary. If the canary shows no errors, gradually increase its weight. If errors appear, set canary weight to 0 to roll back instantly. This is traffic-splitting based canary deployment.
Circuit Breaking in Service Mesh
apiVersion: policy.linkerd.io/v1beta2
kind: Server
metadata:
name: api-server
namespace: default
spec:
podSelector:
matchLabels:
app: api
port: 8080
proxyProtocol: HTTP/1
---
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
name: api-authz
spec:
server:
name: api-server
client:
meshed:
- serviceAccount:
name: web-frontendLinkerd's authorization policy controls which services can connect to which. The web-frontend service account is authorized to connect to the api-server. Unmeshed clients or unauthorized services are rejected.
Not everything needs a mesh. Critical internal services with high traffic benefit most. Edge services receiving external traffic may not need it. Databases typically run outside the mesh. Evaluate the complexity cost vs the operational benefit.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.