Kubernetes Gateway API

#kubernetes #apigateway #devops

Gateway API in Kubernetes: The Next Evolution in Traffic Management

Kubernetes has become the de facto platform for running containerized applications at scale. But running apps in Kubernetes isn’t just about deploying Pods — it’s about getting external traffic in. For years, the go-to way of doing that was with the Ingress API.
Ingress is the traffic routing mechanism primarily used in the Kubernetes environments. However it comes with several limitations. One such example is, it supports only Layer 7 HTTP based traffic. So,to overcome all the Ingress limitations, the Kubernetes Gateway API was development.

Gateway API, a more powerful and flexible evolution of Ingress. Think of it like moving from an old Nokia phone to a modern smartphone — both make calls, but one unlocks a whole new set of possibilities.

The Gateway API has the following key features-

Protocol Agnosticism:
It provides a unified API for managing different layers of network traffic, from simple L4 TCP/UDP connections to complex L7 application-aware routing based on HTTP and gRPC protocols.
Advanced Request Matching:
It enables sophisticated traffic control by allowing routing decisions
to be based on HTTP request attributes, such as path, header values, and
query parameters.
Cross-Team Routing:
It safely allows traffic from a public entry point to be routed to
applications managed by different teams in different namespaces.
Portability & Standardization:
It reduces lock-in by offering a common, vendor-neutral specification
for ingress configuration, minimizing the reliance on implementation-
specific annotations and making manifests portable across different
Kubernetes environments and ingress controllers.
Consistent API for Mesh & Ingress:
It extends the same routing principles and API objects beyond the
cluster edge into the service mesh, providing a consistent operational experience for both north-south (ingress) and east-west (mesh) traffic
when integrated with providers like Istio and Linkerd.

In summary, the Gateway API is an improved version of Kubernetes Ingress that offers more powerful and flexible traffic management.

Gateway API Controller
As we learned in the Ingress lesson, even though we define routing rules in the Ingress object, the actual routing is handled by the Ingress Controller.

The same concept applies to the Gateway API.

While the Gateway API provides many objects to manage cluster traffic, the actual routing is done by a Gateway API Controller. This controller is not built into Kubernetes. You need to enable them by installing the Gateway API Custom Resource Definitions (CRDs).

Various Gateway API controllers are available, some of them are

Nginx Gateway Fabric
Kong Gateway
Envoy Gateway

How Gateway API Actually Works

One of the coolest things about Gateway API is that it isn’t just “Ingress v2.” It’s built around a component model that makes networking modular, role-based, and flexible. Let’s break it down:

The Core Components

GatewayClass

Defines the “blueprint” for how Gateways are provisioned.

Usually provided by a controller (like NGINX, Traefik, Istio, Cilium).

Example: nginx, istio, or cilium GatewayClass.

Gateway

An instance of a GatewayClass.

Think of it as the data-plane entry point (like a load balancer or proxy).

It defines listeners (ports, protocols, TLS config).

Routes (HTTPRoute, TCPRoute, GRPCRoute, TLSRoute, etc.)

Define how traffic flows once it hits the Gateway.

Each Route type matches a specific protocol.

Routes are attached to Gateways using parentRefs.

Gateway Controller

The real engine under the hood.

Each GatewayClass is implemented by a controller (e.g., nginx-gateway-controller, cilium-gateway-controller).

The controller watches Gateway + Route objects, configures the data plane (like Envoy, NGINX, HAProxy), and applies the rules.

TL;DR:
GatewayClass = template
Gateway = instance (entry point)
Route = traffic rules
Controller = brains that makes it work

Enabling Protocols in YAML

Unlike Ingress (which was HTTP/HTTPS only), Gateway API supports multiple protocols right out of the box. You specify them under the listeners section of the Gateway.

Here’s how:
HTTPS with TLS

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: https-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: my-cert

gRPC Example

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: grpc-gateway
spec:
  gatewayClassName: istio
  listeners:
  - name: grpc
    protocol: GRPC
    port: 50051

How It All Comes Together:

The infra team creates a GatewayClass and provisions a Gateway. This is like dropping a load balancer in front of the cluster.
The app teams create HTTPRoute, TCPRoute, or GRPCRoute objects that attach to the Gateway.
The controller (e.g., Cilium, Istio, NGINX) watches these resources and updates the proxy or load balancer accordingly.
Boom 💥 — traffic flows according to your rules, across multiple protocols, without messy annotations.

Why This Matters

By splitting things into GatewayClass → Gateway → Routes, Kubernetes now supports: