Kubernetes networking has evolved substantially. Ingress provided a central HTTP(S)-focused entry point, but it bundled TLS, listeners, and application routing into a single object, leading to overlapping ownership and a growing reliance on vendor-specific Ingress Controller annotations.
The Gateway API represents a shift in design principles, introducing role-oriented resources that cleanly separate infrastructure, platform, and application concerns. Its portability, expressiveness, and extensibility create a consistent, shared API across implementations, reducing controller-specific behaviors and enabling clearer boundaries between teams.
Why switch now
- Further development of the Ingress API is effectively frozen. New feature work in Kubernetes networking is focused on the Gateway API, which is documented as the successor to Ingress and has stable core resources (
Gateway,GatewayClass,HTTPRoute). - The community Ingress NGINX project reached its announced March 2026 retirement date. Its maintainers specified that releases, bug fixes, and security updates would end after that point. Existing deployments can continue running, but migration needs to account for that maintenance boundary. See the official Kubernetes retirement announcement.
- Gateway API standardizes more routing behavior, including header and method matching, traffic splitting, and request mirroring. Portability still depends on implementation support: map existing annotations to supported features and check the chosen controller’s conformance before moving traffic.
- It supports more than just HTTP(S): gRPC, TCP, UDP, and TLS routing are part of the spec, making it easier to handle mixed-protocol environments without bespoke, controller-specific config.
- Role-oriented resources (
GatewayClass,Gateway,HTTPRoute,GRPCRoute, and others) map cleanly to infra, platform, and application teams, improving RBAC boundaries and multi-tenancy compared to a single, overloaded Ingress resource. - Production migrations from existing Ingress controllers to Gateway API take time. Teams need to learn the new resource model, and many vendor-specific annotations must be re-evaluated and mapped to Gateway API resources—starting now gives you room to migrate safely rather than under time pressure.
Ownership and attachment
One reason I find this model useful is that the API can express who owns each part of a routing change. A typical three-role arrangement looks like this:
| Resource | Typical owner | Responsibility |
|---|---|---|
GatewayClass | Infrastructure provider | Controller and gateway class |
Gateway | Platform / cluster operator | Listeners and permitted route attachments |
HTTPRoute | Application developer | Application routing and backend selection |
Route attachment requires agreement from both sides: the route names its intended Gateway in parentRefs, and the Gateway listener permits that attachment through allowedRoutes. Application teams can manage routing within the exposure boundary set by platform teams. The Gateway API security model explains these permissions and attachment rules.
These are API responsibilities; they do not require three separate teams. In a small environment, one person can hold several roles. The useful design question is which changes an application owner should make independently and which need coordination with the platform owner. The roles and personas guide describes that flexibility.