Home/Learn/Microservices/Service Mesh (Istio)

Service Mesh (Istio)

Advanced

Deployment

A service mesh injects sidecar proxies (Envoy) alongside every pod; mTLS, traffic policies, retries, and telemetry are handled by the mesh without application changes.

Overview

A service mesh adds a dedicated infrastructure layer for service-to-service communication, handling concerns that would otherwise require library-level code in every service: mTLS (mutual TLS between all pods), traffic management (load balancing, retries, circuit breaking, canary routing), observability (automatic distributed tracing, metrics, access logs), and policy enforcement (rate limiting, authorisation). Istio is the dominant open-source service mesh. It injects an Envoy sidecar proxy into every pod; all inbound and outbound traffic flows through the sidecar, making network policies transparent to application code. The control plane (istiod) distributes configuration to sidecars and manages certificate issuance for mTLS.

Architecture: data plane (Envoy) and control plane (istiod)

Every pod in an Istio mesh has an Envoy sidecar container injected automatically (via MutatingWebhookConfiguration when the namespace has istio-injection=enabled). The sidecar intercepts all TCP traffic via iptables rules. Istiod provides three control plane functions: Pilot (pushes xDS traffic config to sidecars), Citadel (issues mTLS certificates via SPIFFE/X.509), and Galley (config validation).

YAML + CLI — Istio sidecar injection and mTLS enforcement

# Enable Istio sidecar injection for a namespace
kubectl label namespace backend istio-injection=enabled

# Verify sidecars are injected
kubectl get pod -n backend order-service-xyz -o jsonpath='{.spec.containers[*].name}'
# order-service istio-proxy   ← two containers: app + sidecar

# PeerAuthentication — enable mTLS for all services in namespace
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: backend
spec:
  mtls:
    mode: STRICT   # reject all non-mTLS connections (PERMISSIVE=allow both)

# Check mTLS status
istioctl x describe pod order-service-xyz.backend
# Shows: mTLS STRICT, policy, incoming/outgoing port rules

# Mesh-wide mTLS (all namespaces)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system   # root namespace = mesh-wide
spec:
  mtls:
    mode: STRICT

Traffic management: VirtualService and DestinationRule

VirtualService defines routing rules (where to send traffic). DestinationRule defines load balancing policy and circuit breaker settings per destination. Together they enable canary deployments (route 10% of traffic to v2), A/B testing (route by header), retries, timeouts, and fault injection for chaos testing.

YAML — DestinationRule (circuit breaker) and VirtualService (canary + retries)

# DestinationRule — define subsets (v1/v2) and circuit breaker
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: order-service
spec:
  host: order-service
  trafficPolicy:
    connectionPool:
      http:
        h2UpgradePolicy: UPGRADE
    outlierDetection:
      consecutive5xxErrors: 3
      interval: 30s
      baseEjectionTime: 30s    # circuit breaker: eject after 3 errors
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

---
# VirtualService — canary: 90% → v1, 10% → v2
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: order-service
spec:
  hosts:
    - order-service
  http:
    - route:
        - destination:
            host: order-service
            subset: v1
          weight: 90
        - destination:
            host: order-service
            subset: v2
          weight: 10
      timeout: 5s
      retries:
        attempts: 3
        perTryTimeout: 2s
        retryOn: "5xx,reset,connect-failure"

Observability: automatic telemetry from sidecars

Envoy sidecars automatically emit metrics, access logs, and distributed traces for every request — without application code changes. Integrate with Prometheus (metrics), Jaeger/Zipkin (traces), and Grafana (dashboards). Istio's envoy.filters.http.router records request duration, response code, source/destination service, and cluster-level statistics.

YAML — AuthorizationPolicy for RBAC and fault injection for chaos testing

# Kiali — Istio service graph (visualises mesh traffic)
# kubectl port-forward -n istio-system svc/kiali 20001:20001

# AuthorizationPolicy — RBAC at mesh level
# Only order-service can call payment-service POST /payments
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-service-policy
  namespace: backend
spec:
  selector:
    matchLabels:
      app: payment-service
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/backend/sa/order-service"]
      to:
        - operation:
            methods: ["POST"]
            paths: ["/payments"]

# Fault injection — inject 5% 5-second delays for chaos testing
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
    - fault:
        delay:
          percentage:
            value: 5
          fixedDelay: 5s
      route:
        - destination:
            host: order-service

Key Points to Remember

1Istio injects Envoy sidecars into every pod — all traffic flows through the sidecar transparently to the application
2PeerAuthentication STRICT enforces mTLS between all pods in the namespace — no plaintext service-to-service traffic
3VirtualService defines routing rules (canary weights, header-based routing); DestinationRule defines load balancing and circuit breaker
4Retries, timeouts, and circuit breakers are configured in VirtualService/DestinationRule — no Resilience4j library needed
5Sidecars emit automatic telemetry (metrics, traces, access logs) to Prometheus/Jaeger without application instrumentation
6AuthorizationPolicy implements RBAC at the mesh level — restricts which services can call which endpoints

Interview Questions

What problem does a service mesh solve that application-level libraries like Resilience4j also address?

MediumGoogle

How does Istio enforce mTLS between microservices without application code changes?

MediumThoughtworks

What is the difference between VirtualService and DestinationRule in Istio?

MediumAmazon

How would you implement a canary deployment routing 5% of traffic to v2 using Istio?

HardNetflix

What are the operational costs of running a service mesh and when is it not worth the complexity?

HardUber

Ask Aria about Service Mesh (Istio)

Your personal AI tutor — ask anything about this concept

Revision Status

Personal Notes

Discussion

Loading discussion…

Canary Deployment

Strangler Fig Pattern