Interview › Istio & Service Mesh
How do you capacity-plan the ingress gateway?
Istio & Service Mesh · Advanced level
Answer
I capacity-plan the ingress gateway like a shared production load balancer. I estimate peak RPS, concurrent connections, TLS handshakes, payload size, response size, header size, route complexity, retry behavior, CPU, memory, network throughput, and availability requirements.
Technical explanation
TLS termination and high-cardinality telemetry can be CPU expensive.
Gateway autoscaling should use meaningful signals such as CPU, request rate, active connections, and latency where available.
The gateway deployment needs pod anti-affinity, PDBs, readiness, load-balancer health checks, and safe rollout strategy.
Hands-on example
Capacity test:
$ fortio load -qps 5000 -c 200 -t 30m https://app.example.com/
Watch ingressgateway CPU, memory, downstream connections, p99 latency, 5xx, TLS errors, and node network.
Set HPA and resource requests based on tested headroom, not averages from quiet periods.
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?