Gateway API Resources

Info

The Ingress and Gateway API are two different approaches to managing ingress traffic in Kubernetes. Whilst you can use both in the same cluster, you would generally want to use one or the other for a given application. The Gateway API is the next generation of ingress management, and is recommended for new applications.

The Gateway API introduces a modular, flexible way to manage traffic into your Kubernetes cluster. Unlike the traditional Ingress resource, Gateway API splits responsibilities across several resource types, allowing for more advanced routing, security, and operational models.

What Does a Gateway API Resource Do?

  • Separation of Concerns - Routing, TLS, and infrastructure are managed by different resources, enabling clearer roles and easier delegation.
  • Advanced Routing - Supports host, path, header, and method-based routing, as well as traffic splitting and more.
  • Scalability - Designed for large, multi-team, or multi-tenant environments.

Key Gateway API Resources

  • GatewayClass: Defines the type of gateway (e.g., Application Gateway for Containers).
  • Gateway: Represents the actual gateway instance (already created in your scenario).
  • HTTPRoute: Specifies routing rules for HTTP(S) traffic.
  • ReferenceGrant, TLSRoute, etc.: Additional resources for advanced scenarios.

Gateway Flow Gateway Flow

Role-Based Resource Separation with Gateway API

A key aim of the Gateway API is to enable clear separation of responsibilities between different teams within an organization. With Gateway API, resources are designed so that:

  • Platform or Network Teams can manage the Gateway and GatewayClass resources. This allows them to control infrastructure-level concerns such as which load balancer is used, how domains are mapped, and how TLS certificates are managed.
  • Application Developers can independently define HTTPRoute (and other route) resources. This lets them manage application-specific routing logic — such as which paths or hosts map to which services — without needing access to infrastructure or sensitive credentials.

This separation makes it easier to delegate permissions, maintain security boundaries, and streamline collaboration between teams. It also supports larger organizations where network and application responsibilities are handled by different groups.

Example Gateway Resource

In this example, an instance of traffic handling infrastructure is programmed to listen for HTTP traffic on port 80. Since the addresses field is unspecified, an address or hostname is assigned to the Gateway by the implementation’s controller. This address is used as a network endpoint for processing traffic of backend network endpoints defined in routes.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80

Example HTTPRoute Resource

In this example, HTTP traffic from Gateway example-gateway with the Host: header set to www.example.com and the request path specified as /login will be routed to Service example-svc on port 8080.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-httproute
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "www.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /login
    backendRefs:
    - name: example-svc
      port: 8080