Interview › Istio & Service Mesh
How do you troubleshoot a request that is failing only inside the mesh?
Istio & Service Mesh · Intermediate level
Answer
For a request failing only inside the mesh, I isolate whether the failure is routing, mTLS, authorization, endpoint discovery, gateway configuration, or application behavior. I compare direct pod behavior, Service behavior, and meshed behavior rather than assuming it is an application bug.
Technical explanation
Start with status: pod readiness, sidecar injection, proxy sync, and istioctl analyze.
Then inspect Envoy route, cluster, listener, endpoint, and secret config on the source and destination.
Finally inspect proxy access logs for response flags such as UF, NR, UO, RBAC, or TLS errors.
Hands-on example
Runbook:
$ istioctl analyze -n app
$ istioctl proxy-status
$ istioctl proxy-config route deploy/source -n app
$ istioctl proxy-config endpoints deploy/source -n app | grep destination
$ kubectl logs deploy/source -c istio-proxy -n app --tail=100
Map the error code to route, endpoint, mTLS, or policy.
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?