Ingress gave Kubernetes an important common entry point, but many teams have stretched it far beyond the original abstraction. As traffic management needs become more expressive, the old pattern of annotations and controller-specific extensions becomes harder to reason about.

Gateway API is a better direction because its resource model is clearer from the start.

Separate the gateway from the routes

Gateway API distinguishes between the infrastructure entry point and the route rules that attach to it. That matters operationally because the team that owns public edge configuration is often not the same team that owns every application-specific route.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public-web
  namespace: edge
spec:
  gatewayClassName: cilium
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      hostname: app.example.com
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: apps
spec:
  parentRefs:
    - name: public-web
      namespace: edge
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: app-service
          port: 8080

This is a cleaner operating model than asking one ingress object to represent every concern at once.

Route behavior becomes more expressive

Gateway API was designed for more than “send this host to that service.” Its route resources support richer matching and routing behavior in a portable API model. That gives teams a better long-term path for traffic shaping without turning everything into controller-specific annotations.

It fits larger organizations better

The role-oriented model becomes more important as clusters grow. Shared edge infrastructure, multi-team namespaces, and multiple routes attaching to the same gateway are common realities in serious environments. Gateway API is better suited to that than a flat ingress story.

Closing view

Gateway API is not only a newer interface. It is a more coherent one. For teams that expect their Kubernetes traffic model to grow in complexity, adopting Gateway API is usually less about novelty and more about reducing ambiguity in how routing ownership is expressed.