Interview › Istio & Service Mesh
How do you ensure the sidecar is ready before the app starts taking traffic?
Istio & Service Mesh · Advanced level
Answer
I ensure the sidecar is ready before traffic by using Istio's proxy readiness integration, Kubernetes readiness probes, and, for workloads that make early outbound calls, holdApplicationUntilProxyStarts or equivalent proxy-start ordering. The service should not receive traffic until both app and proxy are ready.
Technical explanation
If only the application readiness is checked, Kubernetes may send traffic before Envoy has listeners and clusters.
Istio can rewrite HTTP probes so health checks work through sidecar interception.
For strict startup dependencies, hold the app until the proxy starts to avoid bootstrap failures.
Hands-on example
Validation:
$ kubectl describe pod <pod> -n app | grep -A5 Readiness
$ kubectl get pod <pod> -n app -o jsonpath='{.status.containerStatuses[*].ready}'
$ kubectl logs <pod> -c istio-proxy -n app | grep -i ready
Run a rolling restart while a client sends continuous requests and check for startup 503s.
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?