Ingress and Gateway API bring HTTP traffic in
A LoadBalancer Service per application is costly. Ingress provides one entry point that routes by hostname and path to many Services. Crucially the Ingress object is only a set of rules: nothing happens unless an Ingress controller (NGINX, Traefik, HAProxy, or a cloud controller such as GKE's or the AWS Load Balancer Controller) is running to implement them. This is the same declaration-versus-implementation pattern as CNI and CSI.
Ingress has real limits. It is one flat object, so platform and application concerns are mixed. Anything beyond host and path matching lives in controller-specific annotations that are not portable, and there is no standard field for traffic splitting. Gateway API addresses this with three resources and three owners: a GatewayClass chooses the implementation, a Gateway defines listeners and is owned by the platform team, and HTTPRoutes owned by application teams attach to a Gateway and define routing, including weighted backends for canaries.
In practice: Ingress remains valid for straightforward routing and is not disappearing overnight, but a well-known ingress controller project has been announced for retirement, so plan migration for important clusters. Gateway API is the direction of travel and is supported by GKE, EKS (through the AWS Load Balancer Controller and VPC Lattice), AKS and on-prem implementations such as Envoy Gateway, Istio and Cilium. Deck 7 covers it in depth.
Reveal the Gateway API roles with the right arrow, then the weighted route to a stable Service and a canary.