Day 17: Istio Architecture

Phase 3 · Jul 17, 2026

Agenda (2–3 hours)

• Read (45 min): Istio architecture documentation; istiod components overview; Istio API reference (VirtualService, DestinationRule)
• Study (45 min): Trace how a VirtualService resource in Kubernetes results in an Envoy route configuration
• Practice (45 min): Deploy a sample app to Istio; create a VirtualService that splits traffic 80/20 between two versions
• Challenge (30 min): How does Istio's Citadel component issue and rotate workload certificates? What SPIFFE concepts does it use?

istiod: The Unified Control Plane

In Istio 1.5+, all control plane components merged into istiod:

istiod watches Kubernetes resources (Services, Endpoints, VirtualServices, DestinationRules) and translates them into xDS configurations for Envoy.

Traffic Management Resources

VirtualService: defines routing rules (where to send traffic)

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata: { name: reviews }
spec:
  hosts: [reviews]
  http:
  - match: [{ headers: { x-version: { exact: "v2" } } }]
    route: [{ destination: { host: reviews, subset: v2 } }]
  - route:
    - destination: { host: reviews, subset: v1 }
      weight: 80
    - destination: { host: reviews, subset: v2 }
      weight: 20

DestinationRule: defines traffic policies (load balancing, circuit breaking, TLS)

kind: DestinationRule
spec:
  host: reviews
  subsets:
  - name: v1
    labels: { version: v1 }
  - name: v2
    labels: { version: v2 }
  trafficPolicy: { connectionPool: { http: { http1MaxPendingRequests: 100 } } }

Sidecar Injection

Two modes:

1. Automatic: namespace labeled istio-injection=enabled → admission webhook injects sidecar
2. Manual: istioctl kube-inject -f deployment.yaml

What gets injected:

• istio-proxy (Envoy) container
• istio-init container (sets up iptables rules)
• Volume mounts for certificates and configuration

The iptables rules redirect all traffic to/from the pod through the Envoy proxy on port 15001 (outbound) and 15006 (inbound).

Certificate Management

Istio Citadel:

1. Issues a root CA (stored in a Kubernetes Secret)
2. For each workload, Envoy calls the SDS API to request a certificate
3. istiod/Citadel issues an X.509 cert with a SPIFFE SVID URI: spiffe://cluster.local/ns/<namespace>/sa/<serviceaccount>
4. Certificates rotate before expiry (default 24h cert lifetime)

This zero-touch certificate rotation is how mTLS is maintained without human intervention.

Key Takeaways

• istiod is the single control plane binary: Pilot (routing) + Citadel (certs) + Galley (validation)
• VirtualService defines routing; DestinationRule defines traffic policy — they compose
• Sidecar injection is transparent (iptables redirect); no app code changes
• Citadel's SPIFFE-based certificate lifecycle provides automatic, rotating mTLS for all services

Tomorrow: mTLS in service mesh — SPIFFE/SPIRE and X.509 SVIDs.