Skip to main content

Gateway API: The Ingress Successor

For years, the Ingress resource was the standard way to get traffic into a cluster. However, it was too simple, leading to a mess of vendor-specific "Annotations" to handle things like Header Matching or Canary splitting.

The Gateway API is the modern, expressive, and role-oriented successor.

1. Role-Based Separation​

One of the biggest improvements is how it splits responsibilities between different teams.

GatewayClass
kind: GatewayClass
controller: acme.io/gateway

Defines the implementation (e.g. AWS, Nginx, Istio).

Gateway
kind: Gateway
listeners:
- port: 80

Defines the entry point (IP, Port, TLS).

HTTPRoute
kind: HTTPRoute
rules:
- matches: /api

Defines routing rules for specific apps.

Admins manage the shared infrastructure (GatewayClass & Gateway).
  • Infrastructure Admin: Manages GatewayClass and Gateway (The physical Load Balancer, IPs, and TLS Certs).
  • Application Developer: Manages HTTPRoute (The actual URL paths and backends for their specific app).

2. Key Resources​

GatewayClass​

Defines a set of Gateways with a common configuration. Managed by the infrastructure provider (e.g., "Standard Public LB").

Gateway​

The instantiation of a GatewayClass. It defines where the traffic listens (e.g., Port 443 on a specific IP).

HTTPRoute / GRPCRoute / TCPRoute​

The routing logic. Developers can now do complex things natively that used to require annotations:

  • Header-based routing: Send traffic to v2 if User-Agent is iPhone.
  • Traffic Splitting: Send 10% of traffic to a canary service.
  • Request Redirects/Rewrites.

Why switch?​

If you are starting a new project, use the Gateway API. It is the future standard, supported by Istio, Cilium, Nginx, and all major cloud providers.

💬 Feedback & Comments

Have a question or found a bug? Leave a comment below using your GitHub account.