Interview › Istio & Service Mesh
How does automatic sidecar injection work (namespace label, webhook)?
Istio & Service Mesh · Basic level
Answer
Automatic sidecar injection uses a Kubernetes mutating admission webhook. When a pod is created in a labeled namespace, the webhook patches the pod spec to add the istio-proxy container, volumes, environment, lifecycle settings, and traffic-redirection configuration.
Technical explanation
The classic label is istio-injection=enabled. For revision-based installs, teams use istio.io/rev or a revision tag.
Injection only happens when the pod is created, so existing pods must be restarted after a namespace label change.
Injection can be disabled per pod with sidecar.istio.io/inject: 'false' when a workload must stay outside the mesh.
Hands-on example
Example:
$ kubectl label namespace app istio.io/rev=stable --overwrite
$ kubectl rollout restart deployment -n app
$ kubectl describe pod -n app <pod> | grep -A3 istio-proxy
If the pod has only one container, check namespace labels, webhook status, and pod annotations.
Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.
More Istio & Service Mesh interview questions
- What is Istio, and what are the core capabilities it provides?
- What is the difference between the Istio control plane and data plane?
- What is istiod, and what does it do?
- What is Envoy, and what role does it play in Istio?
- What is the sidecar pattern, and how does Istio inject the proxy?
- What is the Istio ambient (sidecarless) mode, and how does it differ from sidecar mode?
- What is the difference between ztunnel and a waypoint proxy in ambient mode?
- What problem does Istio solve that Kubernetes Services alone do not?