Implementing Service Mesh
1. Understanding Service Mesh Architecture
| Plane | Role |
|---|---|
| Data plane | Sidecar proxies handle traffic (Envoy) |
| Control plane | Configures proxies (Istiod, linkerd-control) |
| Sidecar pattern | One proxy per pod; transparent interception |
| Sidecarless | eBPF-based (Cilium), Istio Ambient mode |
2. Using Sidecar Proxies
| Function | Detail |
|---|---|
| L7 routing | HTTP/gRPC aware |
| mTLS termination | Encrypt all in-cluster traffic |
| Retries / timeouts | Configured via CRDs |
| Telemetry | Auto metrics, logs, traces |
| Cost | +CPU/RAM per pod, +latency (~1–2ms) |
3. Implementing Traffic Management
| Capability | Mechanism |
|---|---|
| Routing | VirtualService (Istio), HTTPRoute (Gateway API) |
| Header-based | Match on header for routing |
| Mirroring | Send copy to test version |
| Subsets | Group endpoints by labels (version) |
4. Using Circuit Breaking
| Setting | Detail |
|---|---|
| Max connections | Limit pool to upstream |
| Max pending requests | Bounded queue |
| Max retries | Cap retry budget |
| Outlier detection | Eject host after N consecutive 5xx |
5. Implementing Load Balancing
| Algorithm | Notes |
|---|---|
| ROUND_ROBIN | Default |
| LEAST_REQUEST | Power of two choices |
| RANDOM | Simple, low state |
| RING_HASH | Sticky by header (sessions) |
| LOCALITY_WEIGHTED | Prefer same zone |
6. Managing mTLS
| Aspect | Detail |
|---|---|
| Identity | SPIFFE SVID (e.g. spiffe://cluster/ns/svc) |
| Cert rotation | Auto via control plane (24h default) |
| Modes | STRICT, PERMISSIVE, DISABLE |
| Migration | Start PERMISSIVE, ratchet to STRICT |
7. Implementing Traffic Splitting
Example: Istio canary 90/10
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata: { name: orders }
spec:
hosts: [orders]
http:
- route:
- destination: { host: orders, subset: v1 }
weight: 90
- destination: { host: orders, subset: v2 }
weight: 10
| Use Case | Strategy |
|---|---|
| Canary | Small % to new version |
| Blue/Green | Switch 100% atomically |
| A/B | Header/cookie-based |
8. Using Fault Injection
| Fault | Use |
|---|---|
| Delay | Inject latency to test timeouts |
| Abort | Return HTTP error to test fallbacks |
| Scope | Per-route, per-header (canary users only) |
| Goal | Validate resilience without chaos to prod |
9. Implementing Request Routing
| Match | Example |
|---|---|
| URI | prefix, exact, regex |
| Method | GET, POST, ... |
| Headers | e.g. x-user-tier: premium |
| Query params | e.g. beta=true |
| Source labels | From specific service |
10. Managing Service Policies
| Policy | Detail |
|---|---|
| AuthorizationPolicy | Who can call what (RBAC) |
| PeerAuthentication | mTLS modes per workload |
| RequestAuthentication | JWT validation |
| RateLimit (EnvoyFilter) | Global/local rate limiting |
| Telemetry | Sampling, custom metrics |
11. Implementing Observability
| Signal | Tool |
|---|---|
| Metrics | Prometheus (mesh exposes RED auto) |
| Traces | Jaeger, Tempo via B3/W3C |
| Logs | Access logs to stdout → Loki/ELK |
| Topology | Kiali (Istio) |
12. Comparing Istio vs Linkerd vs Consul Connect
| Aspect | Istio | Linkerd | Consul Connect |
|---|---|---|---|
| Proxy | Envoy | linkerd2-proxy (Rust) | Envoy |
| Footprint | Heavy | Light | Medium |
| Features | Most extensive | Focused, simple | Multi-runtime (VM+K8s) |
| Learning curve | Steep | Gentle | Medium |
| mTLS | Yes | Yes | Yes |
| Best for | Complex K8s estates | K8s, simplicity-first | Hybrid VM/cloud |