Part 2 · 2 chapters · ~12 min
Istio and Linkerd
Istio's istiod and Envoy data plane, VirtualService, DestinationRule, PeerAuthentication and AuthorizationPolicy, Linkerd's Rust micro-proxy and minimal configuration, mTLS modes, traffic management, observability out of the box, and choosing between them.
5
Two meshes compared
code
# Istio: strict mTLS for the namespace, a 90/10 canary, and an authorisation rule
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata: { name: default, namespace: payments }
spec: { mtls: { mode: STRICT } }
---
apiVersion: networking.istio.io/v1
kind: VirtualService
spec:
hosts: [ledger]
http: [ { route: [ { destination: { host: ledger, subset: v1 }, weight: 90 }, { destination: { host: ledger, subset: v2 }, weight: 10 } ],
timeout: 2s, retries: { attempts: 2, retryOn: connect-failure,refused-stream } } ]
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
spec:
selector: { matchLabels: { app: ledger } }
rules: [ { from: [ { source: { principals: ["cluster.local/ns/payments/sa/transfers"] } } ] } ]ISTIO AND LINKERD
two control planes, two data planes, one job
swipe the figure sideways, or tap expand for full screen
1/4
Istio
Istio's istiod translates Kubernetes resources (VirtualService, DestinationRule, PeerAuthentication, AuthorizationPolicy) into Envoy xDS and acts as the certificate authority.
Istio = istiod + EnvoyVirtualService, DestinationRule, policies
6
Operating a mesh
| task | how |
|---|---|
| roll out mTLS safely | PERMISSIVE mode first (accepts both), watch which clients still send plain text, then STRICT |
| upgrade the mesh | canary control plane revisions (Istio revision labels), then restart workloads onto new proxies |
| debug a 503 | istioctl proxy-status, istioctl analyze, the sidecar's config dump and access logs (UH, UF, URX response flags) |
| see the graph | Kiali (Istio) or Linkerd viz: live service graph with success rates and latencies |