Route traffic with the Gateway API

The Gateway API is the newer method for routing HTTP traffic in Kubernetes. Where Ingress consolidates everything into one object and one set of annotations, the Gateway API splits the work across typed resources: a cluster operator owns the Gateway (the entry point and its listeners), and application teams own HTTPRoute objects (the host and path rules). Use it when you need that role split or richer routing than Ingress annotations provide.

Like an ingress controller, a Gateway controller is a reverse proxy pod (Envoy, Cilium's, or Traefik) plus a controller that translates your Gateway and HTTPRoute objects into that proxy's configuration. The Gateway API changes how you write the routing, not what serves it: a proxy still receives each request and forwards it to your backend.

Gateway API compared to Ingress#

Not enabled by default#

The platform includes no Gateway API controller, just as it includes no ingress controller. You install the Gateway API custom resources and a controller that implements them. Common choices are Cilium's Gateway API support and Envoy Gateway; several ingress controllers, including Traefik , also implement the Gateway API. As with ingress controllers, running more than one is a supported configuration: each Gateway controller's type: LoadBalancer Service is its own load balancer and public IP, so a cluster can have several entry points.

		$ kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml
	

		apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web
spec:
  gatewayClassName: cilium
  listeners:
    - name: http
      port: 80
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
spec:
  parentRefs:
    - name: web
  hostnames:
    - my-app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: my-app
          port: 80
	

The application responds on my-app.example.com once its DNS A record points to the Gateway's load balancer.

TLS on the listener#

You terminate HTTPS by adding an HTTPS listener to the Gateway and naming the certificate Secret there, rather than in a tls block on the route:

		listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
        - name: my-app-tls
	

cert-manager populates that Secret and renews it, the same as it does for Ingress. For the Ingress equivalent of this handoff, see Terminate TLS at the ingress .

When to prefer it over Ingress#

Use the Gateway API when several teams share one entry point and you want them to own their own routes without editing a shared Ingress, or when you need header-based routing, traffic splitting by weight, or cross-namespace routing that Ingress cannot express. For a single team exposing a small number of HTTP applications, Ingress with a controller such as Traefik remains the simpler option.

Next#

• Terminate TLS at the ingress for the Ingress equivalent of the HTTPS listener above.
• Serve multiple domains and wildcards to hold many hosts behind one entry point.
• Install Traefik if you prefer to stay on Ingress.