Skip to content

SYSTEM Cited by 1 source

Kubernetes Gateway API

Kubernetes Gateway API is the successor to Kubernetes Ingress for modeling external access to in-cluster services. It is a role-oriented API: an infrastructure team runs a Gateway (the listening edge infrastructure), and application teams attach routes to it via parentRefs — decoupling "who runs the edge" from "who exposes a service." Where Ingress is a single HTTP-centric resource, the Gateway API splits responsibilities across GatewayClass, Gateway, and protocol-specific route kinds (HTTPRoute, TLSRoute, TCPRoute, GRPCRoute).

The Gateway API CRDs are not built into Kubernetes core — they must be installed separately (e.g. the standard-install.yaml release bundle) alongside a Gateway controller implementation: Envoy Gateway, Istio, Cilium, or NGINX Gateway Fabric.

Why it beats Ingress for non-HTTP protocols

Ingress is HTTP-centric, which is a poor fit for protocols like Kafka where clients must reconnect to specific brokers by hostname. The Gateway API's TLSRoute allows SNI-based routing: the route matches on the TLS Server Name Indication hostname, so a client reconnecting to broker-3.example.com is routed to the right backend at L4 without terminating TLS.

The canonical framing (Redpanda Operator v26.2 adopting the Gateway API):

"Ingress was never a great fit for the Kafka protocol. It's HTTP-centric, and Kafka clients need to reconnect to specific brokers by hostname. The Kubernetes Gateway API is a much better model where an infrastructure team runs a Gateway, and Redpanda attaches routes to it." (Source: sources/2026-08-11-redpanda-multi-region-high-availability-for-kafka-workloads-with-a-single-stretch-cluster)

Route kinds seen in production

  • HTTPRoute — L7 HTTP routing by hostname/path. Used for web UIs (e.g. Redpanda Console). GA in Redpanda's integration.
  • TLSRoute — L4 routing by SNI without terminating TLS. Used for the Kafka protocol: a bootstrap route plus one per-broker route, so the SNI a client reconnects on matches what the Gateway routes by. Beta in Redpanda's integration.
  • (Also in the spec: TCPRoute, GRPCRoute, UDPRoute.)

Deployment model — separation of concerns

The Gateway resource is deliberately owned by the infrastructure team, not created by the application chart. Applications reference an existing Gateway via parentRefs and only manage their own routes. In Redpanda's chart, "the chart deliberately does not create the Gateway itself. That's the infra team's job, so you reference it via parentRefs." This is the route-attachment model: one shared edge, many app-owned routes.

Gateway and Ingress listeners are mutually exclusive on a given Redpanda listener — enabling both fails fast; switching is a clean swap (remove the gateway stanza, add ingress, and the operator deletes the HTTPRoute and creates an Ingress instead). Because it's opt-in per listener, a service can migrate Kafka to a TLSRoute while leaving Admin or Schema Registry on a conventional NodePort/LoadBalancer.

Seen in

Last updated · 766 distilled / 2,225 read