Istio Gateway vs Kubernetes Ingress
edge traffic models.
Ingress is a simple built-in L7 entry abstraction; an Istio Gateway configures only ports and hosts at the edge while VirtualServices do routing, unlocking mesh features.
What's really being asked
Whether you understand that an Istio Gateway and a Kubernetes Ingress solve overlapping problems with different separations of concern, and when each fits.
The full answer
A Kubernetes Ingress is a built-in resource that, in one object, expresses host and path routing rules and TLS for HTTP traffic, realized by an ingress controller such as nginx. It is simple but limited and historically extended through controller-specific annotations. An Istio Gateway is narrower by design: it configures the edge proxy's exposed ports, protocols and hostnames and TLS termination, but it does no request routing on its own. Routing is delegated to a VirtualService bound to that Gateway, which is where you express path rules, weighted traffic splits for canaries, retries, timeouts and header manipulation. This split lets edge traffic enter the same mesh data plane and inherit mTLS, telemetry and policy. Use plain Ingress when you only need basic host and path routing and are not running a mesh. Use a Gateway plus VirtualService when Istio is already present and you want its advanced traffic management at the edge. They can coexist; some teams keep Ingress for legacy paths while migrating to Gateway.
The mistakes people make
Saying the Istio Gateway does routing by itself like Ingress; it only opens the door, the VirtualService routes. Believing Ingress can do weighted canary or retries natively without controller-specific hacks. Conflating either with the newer Kubernetes Gateway API, which is a separate evolving standard.
What usually comes next
Where does the Kubernetes Gateway API fit and how does it generalize both? How does TLS termination differ? Can you mix an ingress controller and an Istio Gateway in one cluster? How does north-south traffic gain mesh observability through the Gateway?
A concrete example
You expose shop.example.com. With Ingress you write one resource mapping that host and the /api path to a Service, with TLS in the same object. With Istio you write a Gateway declaring port 443 and host shop.example.com with TLS, then a VirtualService bound to it that routes /api ninety percent to checkout v1 and ten percent to v2, something Ingress cannot express cleanly.
Interview question
A colleague writes only an Istio Gateway expecting traffic to reach their service, but requests are not routed. What did they miss compared to using a Kubernetes Ingress?
- a.Ingress and Gateway are interchangeable, so nothing was missed
- b.Istio Gateways cannot terminate TLS, so the request is dropped
- c.The Gateway needs an annotation to enable routing
- d.A Gateway only exposes ports and hosts; a bound VirtualService must define the routingCorrect
Why? this is the answer
An Istio Gateway only configures edge ports, protocols and hosts; routing is delegated to a VirtualService. A Kubernetes Ingress bundles routing into one object, which is why the Gateway alone does not route.
Just read this? Test yourself on what you have been reading.
Read the original → oneuptime.com
- #istio
- #ingress
- #gateway
- #traffic-management
- #kubernetes
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles