Interview › Istio & Service Mesh
How does traffic flow through an Envoy sidecar for inbound and outbound requests?
Istio & Service Mesh · Basic level
Answer
In sidecar mode, outbound traffic from the application is redirected to the local Envoy sidecar, which applies outbound routing, mTLS, policy, and telemetry before sending to the destination. Inbound traffic reaches the destination sidecar first, then Envoy forwards it to the application container.
Technical explanation
Outbound path: app process -> local Envoy -> destination Envoy or gateway -> destination app.
Inbound path: network -> destination Envoy -> local application port.
Because Envoy is on both sides, Istio can authenticate workload identity, encrypt traffic, produce source/destination metrics, and enforce routing consistently.
Hands-on example
Trace a request:
$ kubectl exec -n app deploy/sleep -c sleep -- curl -s http://reviews:9080/ratings
$ istioctl proxy-config route deploy/sleep -n app
$ istioctl proxy-config cluster deploy/sleep -n app | grep reviews
If the route exists outbound but the destination listener is missing, inspect the destination proxy next.
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?