Service Mesh with Istio

Add mutual TLS, traffic management, and deep observability to service-to-service communication without changing application code.

advanced90 minRead → Lab → Quiz → Practice

🧠 Brain Warm-Up

🧠 Brain Warm-Up: If you want every service-to-service HTTP call inside your cluster to be encrypted and authenticated — but you don't want to add TLS code to 50 microservices — how would you enforce that transparently? Who would terminate the TLS, and where would the encryption keys live?

The Problem: Distributed Systems Complexity

As a system grows from a monolith to microservices, new problems emerge:

Security: How do you ensure every service-to-service call is encrypted and authenticated?
Reliability: How do you add retries, circuit breakers, and timeouts without rewriting every service?
Observability: How do you get request traces across 20 services without adding tracing SDK to each?

A service mesh solves all three by moving this logic out of the application into the network layer.

How a Service Mesh Works: The Sidecar Pattern

Istio injects an Envoy proxy sidecar into every Pod (automatically via MutatingAdmissionWebhook). The sidecar intercepts ALL inbound and outbound traffic using iptables rules — the application process is unaware.

WITHOUT ISTIO                     WITH ISTIO
─────────────────────             ──────────────────────────────────
Pod A (app container)             Pod A
  │ plain HTTP                      │ app container
  ▼                                 │ envoy sidecar ← intercepts traffic
Pod B (app container)               │   (mTLS, retries, metrics)
                                    ▼
                                  Pod B
                                    │ envoy sidecar ← mutual TLS
                                    │ app container

Core Istio Components

┌───────────────────────────────────────────────────────┐
│                  CONTROL PLANE                        │
│                                                       │
│  istiod (Pilot + Citadel + Galley merged)            │
│  ├── Pilot: distributes routing config to sidecars   │
│  ├── Citadel: Certificate Authority (issues mTLS certs) │
│  └── Galley: validates Istio config resources        │
└─────────────────────────┬─────────────────────────────┘
                          │ xDS API (gRPC streaming)
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│                     DATA PLANE (every pod)                      │
│  ┌──────────────────────────────────────┐                       │
│  │ Pod                                  │                       │
│  │  ┌───────────┐    ┌───────────────┐  │                       │
│  │  │ App       │←───│ Envoy Sidecar │  │                       │
│  │  │ Container │───→│ (istio-proxy) │  │                       │
│  │  └───────────┘    └───────────────┘  │                       │
│  │                   Handles:           │                       │
│  │                   • mTLS termination │                       │
│  │                   • retries/timeouts │                       │
│  │                   • metrics/traces   │                       │
│  └──────────────────────────────────────┘                       │
└─────────────────────────────────────────────────────────────────┘

Mutual TLS (mTLS)

Istio's Citadel component acts as a Certificate Authority. It issues short-lived X.509 certificates to every sidecar based on the Pod's ServiceAccount (SPIFFE identity: spiffe://cluster.local/ns/default/sa/web-sa).

Strict mode — sidecars only accept mTLS connections; plain HTTP is rejected
Permissive mode — sidecars accept both mTLS and plain HTTP (migration mode)

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT  # Reject all non-mTLS connections in this namespace

Traffic Management

Istio's VirtualService and DestinationRule resources control how traffic is routed between services — independently of Kubernetes Services:

# Canary deploy: send 10% of traffic to v2
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: web
spec:
  hosts: [web]
  http:
  - route:
    - destination:
        host: web
        subset: v1
      weight: 90
    - destination:
        host: web
        subset: v2
      weight: 10

Observability: The Golden Signals

Because all traffic passes through Envoy sidecars, Istio automatically collects:

Metrics — request rate, error rate, latency (exported to Prometheus)
Traces — distributed traces across all hops (via Jaeger/Zipkin via B3/W3C headers)
Access logs — every request/response with full metadata

This observability is zero-code — no SDK changes required in any application.

←

GitOps with ArgoCD

API Deprecations — Staying Current Across Upgrades

→