Implementing Service Mesh Patterns
1. Service Mesh Pattern
| Aspect | Detail |
|---|---|
| Definition | Infrastructure layer providing service-to-service comms (mTLS, retry, LB, telemetry) |
| Architecture | Data plane (proxies) + Control plane (config) |
| Tools | Istio, Linkerd, Consul Connect, Cilium Service Mesh |
| Benefit | Cross-cutting concerns out of application code |
2. Sidecar Proxy Pattern
| Aspect | Detail |
|---|---|
| Mechanism | Proxy container co-deployed with app container; intercepts traffic |
| Examples | Envoy (Istio), linkerd2-proxy |
| Pros | App language-agnostic; uniform behavior |
| Cons | Resource overhead per pod; latency adds |
| Alternative | Sidecar-less mesh (Cilium, Istio Ambient) |
3. Control Plane Pattern
| Responsibility | Detail |
|---|---|
| Config Distribution | Pushes routing/policy to proxies (xDS API) |
| Service Discovery | Tracks endpoint changes |
| Cert Management | Issues mTLS certs (Citadel/Istio) |
| Telemetry Collection | Aggregates from proxies |
| Examples | Istiod, Linkerd control plane |
4. Data Plane Pattern
| Responsibility | Detail |
|---|---|
| Traffic Interception | iptables redirect to sidecar |
| Routing | L7 routing per request |
| Policy Enforcement | mTLS, authz, rate limit |
| Telemetry | Emit metrics, traces, logs |
| Performance | ~1-5ms latency overhead per hop typically |
5. Service Mesh Security Pattern
| Feature | Detail |
|---|---|
| Automatic mTLS | Identity for every workload; encrypt all traffic |
| AuthorizationPolicy | Allow/deny by SPIFFE identity, namespace, method |
| JWT Validation | End-user auth at sidecar |
| Cert Rotation | Automatic, short-lived (hours) |
6. Traffic Management Pattern
| Capability | Detail |
|---|---|
| Routing Rules | Header / weight / path-based |
| Traffic Splitting | Canary / A-B |
| Retries / Timeouts | Per-route policy |
| Fault Injection | Test resilience (delay, abort) |
| Mirroring | Shadow traffic to new version |
Example: Istio VirtualService Canary
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata: { name: order }
spec:
hosts: [order]
http:
- route:
- destination: { host: order, subset: v1 }
weight: 90
- destination: { host: order, subset: v2 }
weight: 107. Service Mesh Observability
| Signal | Provided By Mesh |
|---|---|
| Golden Metrics | RPS, error rate, latency p50/p95/p99 per service |
| Service Graph | Auto-generated dependency map (Kiali) |
| Distributed Traces | Auto-spans for sidecar hops |
| Access Logs | L7 request/response |
8. Circuit Breaking in Service Mesh
| Setting | Detail |
|---|---|
| maxConnections | Per upstream |
| maxPendingRequests | Queue depth |
| maxRequestsPerConnection | HTTP/2 stream cap |
| Outlier Detection | Eject unhealthy hosts (consecutive 5xx) |
9. Service Mesh Retry and Timeout
| Param | Detail |
|---|---|
| attempts | Total retry count |
| perTryTimeout | Per-attempt cap |
| retryOn | Conditions (5xx, gateway-error, reset) |
| retryBudget | Cap retries vs total req (e.g., 20%) |
10. Canary Traffic Routing
| Strategy | Detail |
|---|---|
| Weighted | Start 1% → 10% → 50% → 100% based on metrics |
| Header-Based | Internal users / specific tenants |
| Auto-Promote | Tools: Argo Rollouts, Flagger watch metrics, advance/rollback |
| Rollback | Immediate weight=0 if SLO breach |