🕸️ What a Service Mesh Provides

A service mesh injects a proxy sidecar into every pod. All network traffic flows through the proxy — giving the mesh control over encryption (mTLS), load balancing, retries, timeouts, circuit breaking, and telemetry without any application code changes.

🔀 Traffic Management

Istio uses VirtualService and DestinationRule CRDs to define routing logic. Traffic decisions happen in the Envoy sidecars — not in kube-proxy or the application.

Canary Release — Weighted Routing

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-app
  namespace: my-app
spec:
  host: my-app
  subsets:
    - name: v1
      labels: { version: v1 }
    - name: v2
      labels: { version: v2 }
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app
  namespace: my-app
spec:
  hosts: [my-app]
  http:
    - route:
        - destination:
            host: my-app
            subset: v1
          weight: 90    # 90% to stable
        - destination:
            host: my-app
            subset: v2
          weight: 10    # 10% canary

Header-Based Routing (A/B Testing)

# Route internal testers to v2 via header
spec:
  http:
    - match:
        - headers:
            x-canary:
              exact: "true"
      route:
        - destination: { host: my-app, subset: v2 }
    - route:
        - destination: { host: my-app, subset: v1 }

Retries & Timeouts

spec:
  http:
    - timeout: 10s          # global request timeout
      retries:
        attempts: 3
        perTryTimeout: 3s
        retryOn: "5xx,gateway-error,connect-failure,retriable-4xx"
      route:
        - destination: { host: my-app }

mTLS — Zero-Trust Network

# Enforce strict mTLS for all pods in a namespace
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: my-app
spec:
  mtls:
    mode: STRICT    # reject all plaintext traffic

# Permissive mode — accept both mTLS and plaintext (migration phase)
# mode: PERMISSIVE

# Verify mTLS is working
istioctl x authz check <pod-name>.my-app

AuthorizationPolicy — L7 RBAC

# Only allow frontend to call backend on /api paths
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: backend-policy
  namespace: my-app
spec:
  selector:
    matchLabels: { app: backend }
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/my-app/sa/frontend"]
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/*"]

📊 Observability & Circuit Breaking

Automatic Golden Signals

Every Envoy sidecar emits Prometheus metrics for every service-to-service call — no instrumentation required. Key metrics:

Circuit Breaking (Outlier Detection)

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-app-cb
  namespace: my-app
spec:
  host: my-app
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 5      # eject after 5 consecutive errors
      interval: 10s                # check every 10s
      baseEjectionTime: 30s        # keep ejected for 30s minimum
      maxEjectionPercent: 50       # never eject more than 50% of endpoints

Fault Injection for Chaos Testing

# Inject 5s delay for 10% of requests — test timeout handling
spec:
  http:
    - fault:
        delay:
          percentage: { value: 10 }
          fixedDelay: 5s
    - fault:
        abort:
          percentage: { value: 5 }
          httpStatus: 503       # inject 503 errors for 5% of requests
      route:
        - destination: { host: my-app }

Production Operations

# Useful istioctl commands
# Check all proxies are in sync with control plane
istioctl proxy-status

# Analyse namespace for misconfigurations
istioctl analyze -n my-app

# Dump Envoy config for a pod
istioctl proxy-config all <pod>.<namespace>

# Check effective AuthorizationPolicies
istioctl x authz check <pod>.<namespace>

⚖️ Istio vs Linkerd

When NOT to Use a Service Mesh

• Clusters with < 10 services — NetworkPolicy + TLS at the app layer is simpler
• Teams without dedicated platform engineers to operate the mesh
• Latency-critical paths where adding 5–15ms per hop is unacceptable
• Edge / resource-constrained environments (sidecar overhead is significant)

📝 Knowledge Check