Installing and Sidecar Injection
Installing and Sidecar Injection
istioctl install --set profile=default -y
kubectl label namespace app istio-injection=enabled --overwrite
kubectl apply -f deployment.yaml # sidecar injected at admission
kubectl get pod -n app -o jsonpath='{.items[*].spec.containers[*].name}'
istiod is the control plane: it holds the mesh config, signs workload certificates, and pushes Envoy configuration. The injection webhook adds an istio-proxy container to labeled namespaces' pods; gateways handle north-south traffic. Verify meshes with istioctl proxy-status and check config health with istioctl analyze -n app.
Routing and mTLS Policies
Routing and mTLS Policies
Split traffic by label using a VirtualService plus DestinationRule subsets:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata: { name: api }
spec:
hosts: [api]
http:
- route:
- destination: { host: api, subset: v1 }
weight: 90
- destination: { host: api, subset: v2 }
weight: 10
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata: { name: api }
spec:
host: api
subsets:
- name: v1
labels: { version: v1 }
- name: v2
labels: { version: v2 }
Encryption is policy: PeerAuthentication with mode: STRICT in namespace app requires mesh identity for all traffic there. Ingress uses a Gateway to open ports on the ingress gateway, referenced from VirtualService gateways.
Pitfalls and Interview Angles
Pitfalls and Interview Angles
Missing DestinationRule. A VirtualService referencing subset: v2 with no matching DestinationRule yields 503s or falls back unexpectedly — always define subsets first.
No injection. Pods deployed before the label, or with sidecar.istio.io/inject: "false", bypass the mesh: their traffic lacks mTLS and telemetry, breaking STRICT neighbors.
Egress surprises. STRICT mesh plus outbound calls to external services need a ServiceEntry (or passthrough) or calls fail handshake.
Debug toolkit: istioctl analyze, istioctl proxy-config listeners/routes (alias pc), istioctl proxy-status, and Envoy access logs.
Interview angle: trace a request: client Envoy resolves routes pushed by istiod, applies mTLS, forwards to server Envoy which admits per AuthorizationPolicy — then name your first debugging command.
Quiz
1. Which two objects are required for weighted traffic splitting?
2. What does PeerAuthentication mode STRICT do?
3. A new namespace should join the mesh. What do you do first?
Flashcards
Question
istiod responsibilities
Click to reveal answer
Answer
Config distribution, certificate signing for workload identity, and webhooks — the mesh control plane.
Question
VirtualService vs DestinationRule
Click to reveal answer
Answer
VirtualService: how traffic splits/routes; DestinationRule: subsets, load balancing, and circuit-breaker policies per host.
Question
PeerAuthentication modes
Click to reveal answer
Answer
DISABLE, PERMISSIVE, STRICT — STRICT requires mesh-issued mTLS for all traffic in scope.
Question
istioctl debugging trio
Click to reveal answer
Answer
analyze (config errors), proxy-status (xDS sync), proxy-config (listeners/routes/clusters as pushed to Envoy).
Revision Notes
Key Takeaways
- 1. Injection at admission puts Envoy beside each pod; istiod pushes config and certs
- 2. Weighted routing needs VirtualService + DestinationRule subsets working together
- 3. STRICT mTLS needs every caller in-mesh or excluded — plan the migration explicitly
Interview Tips
- • Trace the request path through both proxies and the control plane before showing YAML
- • Name your first three debug commands for a 503: analyze, proxy-config routes, proxy-status
Cheat Sheet
istioctl install; label ns istio-injection=enabled. VirtualService weights + DestinationRule subsets for canaries; PeerAuthentication STRICT = require mTLS. Debug: analyze, proxy-config, proxy-status.