https://gateway-api.sigs.k8s.io/
https://kubernetes.io/docs/concepts/services-networking/gateway/
The traditional Kubernetes Ingress resource has served as the primary mechanism for exposing HTTP(S) applications to the outside world. It defines host- and path-based routing rules that an Ingress Controller (like NGINX or AWS ALB Ingress Controller) translates into load balancer configurations.
While effective for simple setups, Ingress has several limitations:
Limited expressiveness — routing rules and filters are basic.
Controller-specific annotations — leading to vendor lock-in.
Difficult separation of concerns — operations and developers share the same configuration surface.
The Gateway API was designed by the Kubernetes networking SIG to address these challenges. It introduces a richer and more modular model:
GatewayClass: Defines the type of underlying infrastructure (e.g., AWS ALB).
Gateway: Represents the actual entry point into the cluster.
Route (e.g., HTTPRoute, TCPRoute, GRPCRoute): Defines routing rules, attached to one or more Gateways.
Service: Still used as the backend target for traffic, just like before.
n an AWS EKS cluster, the AWS Load Balancer Controller can interpret Gateway and Route resources to automatically provision and configure AWS Application Load Balancers (ALBs) or Network Load Balancers (NLBs).
A typical traffic flow looks like this:
Client → (AWS ALB via Gateway) → Gateway (reverse proxy) → HTTPRoute → Service → Pod
This is conceptually similar to the classic:
Client → (AWS ALB) → Ingress Controller → Service → Pod
Main take away for me is
Reduced Vendor Lock-In
Gateway API defines a consistent, cloud-agnostic schema.
The same Gateway and Route manifests can work across AWS, GCP, Azure, or on-prem — you only change the GatewayClass to fit the environment. No more provider-specific annotations cluttering your YAML.
Top comments (0)