Ingress Is Fading Away: But Where There Is A Will, There Is A Gateway API

Following the recent announcement of the retirement of the popular Kubernetes Ingress controller, Ingress-Nginx, it is advisable that administrators explore alternatives. While other controllers like Traefik, nginx-ingress, are still good options at the moment, it is clear the community is moving away from Ingress as Kubernetes have made it known that the API itself is no longer actively developed.

---

The Will

Kubernetes is a popular cloud-native platform for deploying, scaling, and managing containerised applications. By default, applications deployed in a Kubernetes cluster are not exposed to the internet, so you need a way to make them accessible and a central way to route traffic to the specific services running in the cluster. This is the solution that Ingress provides.

For years, Ingress has handled routing external traffic to services in a Kubernetes cluster well enough, but it has always had certain limitations that become hard to ignore as your cluster grows and administrative needs expand.

For instance, Ingress natively supports only HTTP(S) routing and TLS termination. Without vendor-specific features, it does not support many advanced traffic management needs like support for other Layer 7 protocols (udp, grpc), content-based routing, session affinity, etc.
To implement any of this, you end up being drowned in a sea of annotations that are non-standard and vary between controllers.

Additionally, while you can restrict access to Ingress via RBAC, there's no native way for, let's say, an admin to manage TLS and a developer to manage routing in the same ingress. The dev would need access to the whole Ingress spec, which could lead to misconfigurations that affects others sharing the controller in a multi-tenant environment.

Not being able to standardise configuration across clusters has become a pain point, and administrators need a way to ensure teams have only the necessary access to perform their jobs, while relying less on other teams.

This is why the development for the Ingress API is being abandoned in favour of the Gateway API (whose idea was first introduced as Ingress 2.0, before that, too, was abandoned).

---

The Gateway API

In October 2023, the Gateway API was announced. It is meant to replace Ingress in the long run and not be an upgrade or new version of the Ingress API.

The Gateway API offers a more structured and extensible traffic management API with clear separation of concerns and standardization across providers of the underlying controllers.

Gateway API breaks traffic management into distinct Kubernetes objects, something Ingress never properly achieved. Instead of one object carrying both infra-level settings and app-level routing with a sea of annotations, Gateway API separates responsibilities cleanly.

The three core objects are:
GatewayClass – defines the implementation (controller)
Gateway – defines the entry point
Route resources – define how traffic should be forwarded (e.g., HTTPRoute, GRPCRoute, UDPRoute)

This structure gives clearer boundaries between infra teams and application teams, and removes the annotation-driven configuration style that made Ingress brittle and inconsistent across controllers.

GatewayClass
Ingress uses annotations to bind an Ingress object to a controller. Gateway API formalises this into a dedicated object.

A GatewayClass declares which controller will implement a Gateway. It’s purely infrastructure-level and usually immutable once defined.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: nginx
spec:
  controllerName: k8s.nginx.org/nginx

Gateway
A Gateway object represents the actual data-plane listener — the equivalent of the load balancer or proxy entrypoint. This is separate from routing logic, so infra teams control where traffic enters and how it is exposed (ports, protocols, hostnames).

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shop
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP

In Ingress, this is similar to the Ingress controller + service load balancer abstraction, but explicitly modeled instead of implicit.

HTTPRoute
Routes define how traffic is matched and forwarded. HTTPRoute replaces the routing rules you’d normally place under spec.rules in an Ingress. The difference is that Gateway API supports richer matching and isn’t tied to the limitations of annotations.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: books
spec:
  parentRefs:
  - name: shop
  hostnames:
  - "shop.books.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: books
      port: 80   

After years of Ingress, you would realise Ingress puts the controller, entry point, and routing logic into a single object, with most controller-specific behaviour hidden behind annotations.

In contrast, Gateway API exposes these responsibilities as objects, resulting in consistent behaviour across controllers, better separation of duties, and routing rules that are easier to reason about.

Conclusion

Ingress is not going away soon, but the ecosystem is already adjusting to a reality where Gateway API becomes the standard way to manage traffic in Kubernetes. Its clearer design, stronger separation of roles, and consistent cross-implementation behaviour make it a more practical long-term choice. Migrating to the Gateway API might be hard, but it should be done gracefully. Analyse your setup, understand your routes and watch out for controller support maturity.