Istio Gateway vs Kubernetes Ingress

WHAT THIS TESTS Whether you understand that an Istio Gateway and a Kubernetes Ingress solve overlapping problems with different separations of concern, and when each fits.

A GOOD ANSWER COVERS 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.

COMMON WRONG ANSWERS 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.

LIKELY FOLLOW-UPS 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?

ONE 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.