Kubernetes Ingress and Gateway Routing Scope

Kubernetes Ingress and Gateway Routing Scope refers to the boundaries of what each routing API is designed to express, which layers of the network stack they operate at, and which combinations of protocols, personas, and cluster topologies each is intended to serve, a distinction that matters because the two APIs coexist rather than one strictly superseding the other.

Ingress API Scope

HTTP and HTTPS Focus

The original Ingress API was scoped narrowly around HTTP and HTTPS routing, expressing rules as host and path matches that direct traffic to a backend Service. This narrow scope was intentional, aiming for a minimal, broadly implementable surface that any controller could support consistently.

Single-Resource Ownership Model

An Ingress resource is typically authored and owned by a single team or namespace, describing routing rules for the applications that namespace controls. This scope works well for straightforward application exposure but becomes limiting when multiple teams need to share a single external entry point with differentiated permissions over different parts of the routing configuration.

Extension Through Annotations

Because the Ingress API's formal schema is intentionally minimal, controllers extend its practical scope through implementation-specific annotations covering behavior like rewrite rules, rate limiting, or custom load balancing, which expands what Ingress can express in practice at the cost of portability between different controller implementations.

Gateway API Scope

Protocol Breadth Beyond HTTP

The Gateway API was designed with a broader scope from the outset, supporting not just HTTP and HTTPS routing but also TCP, UDP, and TLS passthrough routing through a family of distinct route types, GatewayClass, Gateway, and various xRoute resources, each targeting a specific protocol or routing concern.

Role-Oriented Resource Separation

Gateway API deliberately separates infrastructure-level configuration, expressed through GatewayClass and Gateway resources typically managed by a platform or infrastructure team, from application-level routing rules, expressed through Route resources managed by application teams. This scoping decision directly addresses the shared-ownership limitation present in the single-resource Ingress model.

Cross-Namespace Routing Scope

Ingress Namespace Confinement

An Ingress resource can only reference backend Services within its own namespace, which confines its routing scope to a single namespace's applications unless a controller-specific extension mechanism is used to work around this limitation.

Gateway API Cross-Namespace Delegation

Gateway API explicitly supports cross-namespace routing through reference grants, allowing a Route resource in one namespace to target a Gateway defined in a different namespace, with the target namespace able to control which references it accepts, expanding the routing scope to cleanly support shared, multi-tenant ingress infrastructure.

Traffic Splitting and Advanced Routing Scope

Beyond Simple Host and Path Matching

Gateway API's route resources natively support traffic weighting for canary or blue-green style splitting between backend Services, request and response header manipulation, and more granular match conditions, capabilities that sit outside the original Ingress API's scope and were historically only available through controller-specific annotations.

Coexistence Rather Than Replacement

Overlapping but Distinct Adoption Paths

Because Ingress remains widely deployed and Gateway API adoption is still expanding across the ecosystem, many clusters run both simultaneously, often through a shared underlying controller capable of reconciling both APIs, meaning the practical routing scope of a given cluster is frequently the union of what both APIs express rather than an exclusive choice between them.