Ingress NGINX Retirement: Transition to Gateway API for EKS

Kubernetes Ingress API has served us for years but fell short in meeting modern needs (header routing, traffic splitting, etc.). As a solution, every Ingress Controller (NGINX, ALB, Istio) developed its own custom annotations. This destroyed portability.

The Kubernetes community developed the Gateway API standard to solve this problem radically. We are now switching to Gateway API usage as standard in Amazon EKS projects.

What is Gateway API?

Gateway API is a role-based and more flexible networking API that replaces Ingress. It has three main components:

1. GatewayClass: Defines the infrastructure type (e.g., amazon-vpc-lattice).
2. Gateway: Defines the network entry point (Load Balancer).
3. HTTPRoute: Defines traffic rules (Which path goes to which service).

Why Should You Switch?

• Standardization: Offers a common language for different proxies (Envoy, NGINX).
• Role Separation: While the infrastructure team manages the Gateway resource, developers can manage the HTTPRoute resource.
• Advanced Features: Features like Canary deployment (10% traffic to service A), header matching are natively supported.

Implementation on EKS

AWS supports Gateway API via AWS Gateway API Controller or VPC Lattice.

An example HTTPRoute definition:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: my-service
      port: 80

The future Kubernetes networking structure is built on Gateway API. Adapting early prevents technical debt.