Service Mesh with Istio

As microservice architectures grow, managing service-to-service communication becomes increasingly complex. A service mesh provides traffic management, security, and observability without modifying application code. This lesson covers Istio's architecture, traffic routing, security features, and deployment strategies.

---

What Is a Service Mesh?

A service mesh is a dedicated infrastructure layer that handles service-to-service communication. It works by deploying a sidecar proxy alongside every application container.

┌────────────────────────────────┐
│  Pod                           │
│  ┌──────────┐  ┌────────────┐ │
│  │ App      │──│ Envoy      │ │
│  │ Container│  │ Sidecar    │ │
│  └──────────┘  └─────┬──────┘ │
└──────────────────────┼─────────┘
                       │
                       ▼
              ┌──────────────┐
              │ Istiod       │
              │ (Control     │
              │  Plane)      │
              └──────────────┘

Why Use a Service Mesh?

Concern	Without Mesh	With Mesh (Istio)
mTLS encryption	Each app implements TLS	Automatic, zero-code
Traffic splitting	Custom load balancer	Declarative YAML
Retries / timeouts	Application code	Mesh configuration
Observability	Instrument each service	Automatic metrics/tracing
Access control	Application-level auth	Policy-driven

---

Installing Istio

# Download Istio
curl -L https://istio.io/downloadIstio | sh -
cd istio-1.20.0
export PATH=$PWD/bin:$PATH

# Install with the production profile
istioctl install --set profile=default -y

# Enable automatic sidecar injection for a namespace
kubectl label namespace production istio-injection=enabled

# Verify installation
istioctl verify-install
kubectl get pods -n istio-system

---

Traffic Management

VirtualService — Routing Rules

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-routing
spec:
  hosts:
    - reviews
  http:
    - match:
        - headers:
            end-user:
              exact: beta-tester
      route:
        - destination:
            host: reviews
            subset: v2
    - route:
        - destination:
            host: reviews
            subset: v1
          weight: 90
        - destination:
            host: reviews
            subset: v2
          weight: 10

DestinationRule — Traffic Policies

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: DEFAULT
        http1MaxPendingRequests: 100
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 60s
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

---

Canary Deployments with Istio

A canary deployment gradually shifts traffic from the old version to the new one.

Phase 1: 95% v1, 5% v2    (initial canary)
Phase 2: 80% v1, 20% v2   (expand if metrics are good)
Phase 3: 50% v1, 50% v2   (half traffic)
Phase 4: 0% v1, 100% v2   (full rollout)