Service Mesh (Istio) Cheat Sheet
Core Istio concepts for traffic management, mTLS security, and observability using sidecar proxies in a Kubernetes cluster.
Core Istio Components
The main building blocks of an Istio service mesh.
- Envoy sidecar- Proxy injected alongside each pod that intercepts all inbound/outbound traffic
- Istiod- Control plane component handling configuration, certificate issuance, and service discovery
- VirtualService- Defines routing rules for traffic to a service, e.g. weighted splits, retries
- DestinationRule- Defines policies applied after routing, e.g. subsets, load balancing, TLS settings
- Gateway- Configures a load balancer for ingress/egress traffic at the mesh edge
Enable Sidecar Injection
Label a namespace so Istio automatically injects the Envoy sidecar.
kubectl label namespace default istio-injection=enabled# Verify injection on existing pods (requires rollout restart)kubectl rollout restart deployment -n default
Canary Traffic Split
Route 90% of traffic to v1 and 10% to v2 for a canary rollout.
apiVersion: networking.istio.io/v1beta1kind: VirtualServicemetadata: name: reviewsspec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 weight: 90 - destination: host: reviews subset: v2 weight: 10
DestinationRule with Subsets
Define version-based subsets referenced by a VirtualService.
apiVersion: networking.istio.io/v1beta1kind: DestinationRulemetadata: name: reviewsspec: host: reviews trafficPolicy: tls: mode: ISTIO_MUTUAL subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2
Enforce mTLS Cluster-Wide
PeerAuthentication policy requiring strict mutual TLS for the mesh.
apiVersion: security.istio.io/v1beta1kind: PeerAuthenticationmetadata: name: default namespace: istio-systemspec: mtls: mode: STRICT
Envoy-Level Resilience Primitives
Traffic-shaping controls Istio exposes on top of raw Envoy for building resilient service-to-service calls.
- Retries- Per-route retry count, per-try timeout, and retryable status codes/conditions set on a VirtualService
- Timeouts- Overall request deadline enforced independently of any application-level timeout
- Outlier detection- Passive circuit breaking that ejects an unhealthy endpoint from the load-balancing pool after consecutive errors
- Connection pool limits- Caps concurrent TCP connections/HTTP requests per host to protect a backend from being overwhelmed
- Fault injection- Deliberately injects delays or aborts into a percentage of requests to test downstream resilience
- Traffic mirroring- Shadows live traffic to a second version for safe testing without affecting the response the client receives
- Locality load balancing- Prefers routing to endpoints in the same region/zone before failing over to remote ones
Retries and Timeouts
Configure per-try retry budget and an overall request timeout on a VirtualService.
apiVersion: networking.istio.io/v1beta1kind: VirtualServicemetadata: name: reviewsspec: hosts: - reviews http: - timeout: 3s retries: attempts: 3 perTryTimeout: 1s retryOn: 5xx,reset,connect-failure,refused-stream route: - destination: host: reviews subset: v1
Outlier Detection (Passive Circuit Breaking)
DestinationRule that ejects an endpoint returning consecutive 5xx errors from the pool for 30s.
apiVersion: networking.istio.io/v1beta1kind: DestinationRulemetadata: name: reviewsspec: host: reviews trafficPolicy: connectionPool: tcp: maxConnections: 100 http: http1MaxPendingRequests: 50 maxRequestsPerConnection: 10 outlierDetection: consecutive5xxErrors: 5 interval: 10s baseEjectionTime: 30s maxEjectionPercent: 50
Fault Injection for Resilience Testing
Inject a 5s delay into 10% of requests and abort 1% with HTTP 500 to validate downstream retry/timeout handling.
apiVersion: networking.istio.io/v1beta1kind: VirtualServicemetadata: name: ratingsspec: hosts: - ratings http: - fault: delay: percentage: value: 10 fixedDelay: 5s abort: percentage: value: 1 httpStatus: 500 route: - destination: host: ratings subset: v1
ServiceEntry for Controlled Egress
Register an external API host so mesh traffic to it is observable and policy-controlled instead of silently bypassing the sidecar.
apiVersion: networking.istio.io/v1beta1kind: ServiceEntrymetadata: name: external-payments-apispec: hosts: - api.payments-provider.com location: MESH_EXTERNAL ports: - number: 443 name: https protocol: TLS resolution: DNS---# Debug what Envoy actually knows about a workload# istioctl proxy-config cluster <pod> -n <ns># istioctl proxy-config listener <pod> -n <ns># istioctl analyze -n <ns>
Roll out mTLS with `PERMISSIVE` mode first, monitor for failed connections from non-meshed clients, then switch to `STRICT` — jumping straight to strict mTLS commonly breaks traffic from services that haven't been onboarded to the mesh yet.
