Interview › Istio & Service Mesh
What is the sidecar pattern, and how does Istio inject the proxy?
Istio & Service Mesh · Basic level
Answer
The sidecar pattern runs an auxiliary container alongside the application container in the same pod. Istio injects an Envoy sidecar so all inbound and outbound traffic can be intercepted, secured, routed, and observed without changing the application process.
Technical explanation
Injection is usually done by a Kubernetes mutating admission webhook triggered by namespace labels or revision labels.
Traffic redirection is configured by init containers or Istio CNI so application traffic flows through Envoy.
The application still listens on its normal port; Envoy becomes the policy and telemetry enforcement point around it.
Hands-on example
Verify sidecar injection:
$ kubectl label namespace payments istio-injection=enabled
$ kubectl rollout restart deploy -n payments
$ kubectl get pod -n payments -o jsonpath='{.items[0].spec.containers[*].name}'
Expected output includes the application container and istio-proxy.
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?
- How does automatic sidecar injection work (namespace label, webhook)?
- 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?