Interview › Istio & Service Mesh
Why might traffic bypass the sidecar, and how do you verify injection?
Istio & Service Mesh · Intermediate level
Answer
Traffic may bypass the sidecar if the pod was not injected, traffic uses excluded ports or IP ranges, hostNetwork is used, iptables/CNI redirection failed, the app binds or routes unusually, or an operator explicitly disabled injection or capture annotations.
Technical explanation
The first check is whether the pod actually has istio-proxy and the expected annotations.
Then verify sidecar status, listeners, and whether the traffic uses a port included in capture rules.
Bypass can create security gaps because mTLS and AuthorizationPolicy may not apply.
Hands-on example
Verification:
$ kubectl get pod <pod> -n app -o jsonpath='{.spec.containers[*].name}'
$ kubectl get pod <pod> -n app -o jsonpath='{.metadata.annotations.sidecar\.istio\.io/status}'
$ istioctl proxy-config listeners <pod> -n app
If no istio-proxy appears, restart after fixing namespace labels or revision tags.
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?
- 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?