Gateway API 1.0 makes shared routing ownership explicit

Sharing a load balancer creates an ownership problem before it creates a routing problem. An application developer needs to decide where requests go, while a cluster operator needs control over the infrastructure accepting those requests. Giving either party unrestricted ownership of the whole configuration makes the other party depend on an arrangement outside the API. Gateway API was designed to express those responsibilities separately.

The October 31 Gateway API 1.0 announcement promotes GatewayClass, Gateway, and HTTPRoute to v1. Those resources are now generally available, with backwards compatibility guarantees. The significance is a stable model for a relationship that shared clusters already need to manage, including the agreement that allows an application's route to use shared infrastructure.

I place more value on Kubernetes' extensible API machinery than on any particular built-in workload type. Gateway API is a useful example of that machinery supporting a domain-specific model. Its split between infrastructure and routing gives the configuration an ownership structure that an organisation can enforce and review.

Roles explain the resource split

The project's versioned roles and personas document starts from the limitations of the original Ingress usage model. That model assumed the developer exposing an application controlled the relevant decisions. Shared infrastructure introduces different concerns, because the person maintaining the cluster must consider several applications and users together.

Gateway API distinguishes an infrastructure provider, a cluster operator, and an application developer. Its documentation allows one person to fill several roles. The distinction expresses responsibility rather than a mandatory organisation chart. A small installation can retain self-service operation, while a larger one can assign resource management to different people through Kubernetes RBAC.

That is a concrete reason for more than one object. The infrastructure definition and the application's matching rules have different change authorities. Keeping them in distinct resources allows the platform to delegate route management without automatically delegating the infrastructure itself. A resource boundary gives an access-control system something specific to govern.

The division also changes the review context. A listener change concerns the shared point at which traffic enters. A route change concerns how selected requests reach a backend. Both can affect an application's exposure, but neither needs to be described as ownership of a single undifferentiated ingress configuration.

A route requests attachment and the gateway permits it

The 1.0 simple Gateway guide describes a Gateway as an instance of a logical load balancer based on a GatewayClass. Routes name their intended parent through parentRefs. The Gateway must permit that attachment. The guide says routes from the same namespace are trusted by default.

This makes the relationship bidirectional. A route's reference expresses where its author wants it to attach. The Gateway's policy controls which attachments it accepts. A route author cannot establish access to arbitrary shared infrastructure merely by naming it. The infrastructure owner has an independent declaration of the permitted relationship.

A minimal example can use the following Gateway. It assumes a hypothetical acme-lb GatewayClass supplied by an implementation, following the project's example.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-web
spec:
  gatewayClassName: acme-lb
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same

The listener accepts HTTP on port 80 and permits routes from its own namespace. This is a configuration example, not a statement that a cluster already has an implementation providing the named class. Installing API definitions and supplying the controller that acts on them are distinct requirements.

The companion route names that Gateway and directs traffic to a Service.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: application
spec:
  parentRefs:
    - name: prod-web
  rules:
    - backendRefs:
        - name: foo-svc
          port: 8080

This follows the versioned simple-route example, using the newly stable API version. With no hostnames or path matches specified, the guide explains that this route matches HTTP traffic arriving through its parent and sends it to the named backend. Both resources are intended for the same namespace in this example.

Several routes can use one gateway

The project's HTTP routing guide shows separate HTTPRoute objects attached to a shared Gateway. Its examples distinguish requests by hostname and then by paths or headers. Routes can therefore express application-specific routing while sharing the infrastructure that accepts their traffic.

The guide uses separate routes for hosts with different routing requirements. One host routes a login path to a Service. Another uses a header to select a canary backend, with an ordinary backend for other requests. This puts matching and backend choice in the route, where the application owner can manage them, while the Gateway continues to describe the common listener.

Merging routes still needs defined behaviour when their declarations overlap. The guide describes multiple routes binding to a Gateway as long as they do not conflict. The API's value includes specifying these relationships, so implementations and users can reason about shared routing through common resource semantics.

I find that explicit attachment model particularly useful for platform configuration. It gives an application a way to request exposure without requiring an informal handoff for every backend change. The platform retains a policy on which routes can use its listener, and the submitted objects record both sides of that agreement.

General availability has a defined scope

The release announcement names exactly which APIs graduate. It does not declare every Gateway API resource or capability stable. Additional route types and service mesh support remain among the work the project wants to stabilise. Treating the version number of the project as the maturity level of every included API would overstate this release.

Experimental additions in 1.0 include HTTPRoute timeouts, TLS configuration from Gateways to backends, WebSocket support, and Gateway infrastructure labels. The announcement places these in the Experimental channel. They belong to a different adoption decision from using the stable v1 resources in the Standard channel.

Stable also does not mean complete. The authors explicitly say the stable resources will continue receiving functionality through the Experimental channel as additions meet graduation requirements. The compatibility commitment gives existing consumers a basis for relying on the API while that process continues. It does not imply the project has exhausted its routing requirements.

That distinction matters when choosing an implementation. An application's required capability needs to be evaluated at its actual API maturity and implementation support. A declaration using a stable resource name can still depend on a particular experimental field or behaviour. The release's channel distinction preserves that information instead of treating general availability as one undifferentiated label.

CEL removes a separate validation dependency for many clusters

Gateway API 1.0 adds CEL validation rules to its CRDs. The announcement says these rules are supported on Kubernetes 1.25 and newer. The validating webhook previously bundled with installation becomes optional, with installation recommended only for Kubernetes 1.24.

For supported clusters with CEL validation, that moves relevant validation into the API server's handling of the custom resources. A separate webhook is no longer required for most installations. This reduces the infrastructure needed just to install and validate the routing API, while keeping the resource model expressed through CRDs.

Gateway API also has a release lifecycle independent of the Kubernetes minor release. The announcement says users can install 1.0 on the five most recent Kubernetes minors, beginning with 1.24 at this date. Adopting the stable routing model therefore does not require first adopting a newly released Kubernetes minor. The operator still needs compatible CRDs and a controller implementation, while application authors gain the stable resource relationships for declaring their routes.

Cross-namespace references need their own permission

The announcement also discusses ReferenceGrant, which Gateway API uses to enable cross-namespace references safely. The project describes work toward a built-in API under SIG Auth that could serve uses beyond Gateway API. That is future work at this date, with modifications expected during the proposed migration. It should not be treated as an already available built-in resource.

The existing concept reinforces the ownership model. Naming another namespace's resource and having authority to use it are different claims. An API that expresses the permission separately can let the target's owner participate in that decision. This matters when a route and its intended dependency have different administrators.

That is why the minimal example keeps its Gateway and route together. It demonstrates one attachment without hiding an additional permission assumption behind an unexplained namespace reference. Larger installations can use the API's explicit permission mechanisms to describe shared infrastructure and dependencies across ownership boundaries.