Why Ingress Falls Short and How the New Kubernetes Gateway API Solves It

For DevOps engineers entering the Kubernetes world, Ingress is often the first networking resource they encounter, but its design limits modern traffic management needs. This article explains why a new API is required and how the Kubernetes Gateway API addresses those gaps.

Ingress Limitations

Annotation Hell: Advanced features such as rate limiting, URL rewrites, body size limits, and CORS require controller‑specific annotations, causing inconsistency across Nginx, Traefik, HAProxy, etc.

Lack of advanced traffic management: Ingress cannot natively support canary or blue/green deployments without additional tools like service meshes, increasing operational complexity.

Protocol restrictions: Ingress is designed only for HTTP/HTTPS and does not support TCP or UDP traffic.

Why Choose Gateway API?

Recognizing these constraints, the Kubernetes community created the Gateway API, a more extensible, role‑based traffic‑management framework that supports HTTP, HTTPS, TCP, and UDP. It introduces three primary Custom Resource Definitions (CRDs):

GatewayClass: Defines the behavior of a gateway controller (e.g., NGINX Gateway).

Gateway: Represents a network gateway or load balancer, specifying listeners and the protocols/ports it exposes.

Route: Describes how traffic arriving at a Gateway should be routed; includes HTTPRoute, TCPRoute, UDPRoute, etc.

Three‑Layer Architecture and Role Separation

Infrastructure Providers: Manage GatewayClass and decide which Gateway Controllers are available.

Cluster Operators: Create and manage Gateway objects, configuring listeners and basic security.

Application Developers: Define Route objects (e.g., HTTPRoute) to control host, path, header matching, traffic splitting, and rewrites.

Practical Example

Below is a migration from a simple Ingress that routes /message and /swap to two services, to an equivalent Gateway API configuration using three resources.

Step 1: Define GatewayClass

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: k8senol-gw-class
spec:
  controllerName: k8senol.com/gateway-controller

Step 2: Create Gateway

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: k8senol-gateway
  namespace: default
spec:
  gatewayClassName: k8senol-gw-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    hostname: "*.k8senol.com"
    allowedRoutes:
      namespaces:
        from: Same

Step 3: Create HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: k8senol-routes
  namespace: default
spec:
  parentRefs:
  - name: k8senol-gateway
  hostnames:
  - "k8senol.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /message
    backendRefs:
    - name: message-service
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /swap
    backendRefs:
    - name: swap-service
      port: 80

This example shows how a single Ingress manifest is split into three distinct resources, each with a clear responsibility, leading to more maintainable and secure traffic management.

Ingress remains a foundational Kubernetes feature, but as applications grow in complexity, the Gateway API offers role separation, multi‑protocol support, and advanced traffic controls that better serve modern cloud‑native workloads.