Week 16: Service Mesh — Istio & Linkerd Fundamentals

1. The Sidecar Pattern & Data/Control Plane

A service mesh works by injecting a small proxy container — Envoy, in both Istio and (in Linkerd's case, a lighter Rust proxy) — into every Pod, alongside your application container. Every request your app sends or receives is transparently intercepted by that sidecar first. Your application code makes a perfectly ordinary HTTP call to another service's normal address; it has no idea a proxy is involved at all. The sum of every sidecar across the cluster is the mesh's data plane — it's what actually handles traffic. A separate control plane (istiod for Istio) configures every sidecar's behavior centrally and pushes updates out to them.

kubectl label namespace production istio-injection=enabled

# any Deployment applied to this namespace from now on
# automatically gets an Envoy sidecar added to its Pods
kubectl apply -f k8s/orders-deployment.yaml -n production
kubectl get pods -n production
# NAME                     READY   STATUS
# orders-7d9f6b8c4d-x2k9p  2/2     Running   <- 2 containers: app + istio-proxy

That 2/2 is the whole pattern in one line: nothing in orders-deployment.yaml mentions Istio at all, yet every Pod it creates now runs an Envoy proxy alongside the app container, transparently. This is the central appeal of a mesh over building the same capabilities into every service's code — mTLS, retries, and traffic routing become a platform concern configured once, not a library every team has to import and keep in sync.

2. mTLS, Retries, Timeouts & Circuit Breaking

With sidecars in place, Istio can enforce mutual TLS (mTLS) between every service in the mesh — both sides of a connection present and verify a certificate, not just the server — without a single line of application code changing. Certificates are issued and rotated automatically by the control plane.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT   # reject any plaintext traffic between meshed Pods

On top of encryption, the mesh can add resilience patterns directly at the proxy layer — retries on transient failures, timeouts so a slow dependency doesn't stall its caller forever, and circuit breaking so one struggling service doesn't get hammered by callers retrying into it and making the outage worse:

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: inventory-service
spec:
  host: inventory-service
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 20
        maxRequestsPerConnection: 10
    outlierDetection:            # circuit breaking
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s      # eject an unhealthy Pod for 30s
      maxEjectionPercent: 50
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: inventory-service
spec:
  hosts: [inventory-service]
  http:
    - timeout: 2s
      retries:
        attempts: 3
        perTryTimeout: 500ms
        retryOn: 5xx,connect-failure
      route:
        - destination: { host: inventory-service }

outlierDetection is the circuit breaker: after 5 consecutive 5xx responses, that specific Pod is ejected from the load-balancing pool for 30 seconds, which gives it room to recover (or restart) instead of continuing to receive traffic it's already failing to serve. The 2-second overall timeout combined with a 500ms perTryTimeout and 3 retries means a caller gets a definitive answer within 2 seconds no matter what — never an indefinite hang waiting on a dependency that's stopped responding.

3. Traffic Shifting for Canary Releases

Week 15's rolling updates replace old Pods with new ones gradually, but every request still eventually reaches the new version — there's no way to say "send only 10% of traffic there and watch it." A mesh's VirtualService can split traffic by weight across two versions of the same service, running side by side, which is what makes a genuine canary release possible.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: checkout-service
spec:
  hosts: [checkout-service]
  http:
    - route:
        - destination:
            host: checkout-service
            subset: v1
          weight: 90
        - destination:
            host: checkout-service
            subset: v2      # the canary
          weight: 10
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: checkout-service
spec:
  host: checkout-service
  subsets:
    - name: v1
      labels: { version: v1 }
    - name: v2
      labels: { version: v2 }

Both v1 and v2 run as ordinary Deployments distinguished only by a version label — the VirtualService is what decides how traffic splits between them, and that weight is just a number you can change: watch the canary's error rate and latency in your Week 13 dashboards at 10%, then move to 25%, 50%, and 100% only once you trust it, or set the weight back to 0 and delete the canary Deployment in seconds if something looks wrong — no rollback of a Deployment's rollout history required, because the old version never stopped running.

4. Hands-on Exercise

5. Knowledge Check

Three quick questions. Expand each to check your answer.