Gateway API beta makes traffic ownership explicit

Sharing a reverse proxy across applications creates an ownership problem before it creates a routing problem. Someone chooses the implementation and provisions its infrastructure. Someone else decides which listener may expose an application. An application owner needs to describe the requests that belong to a service without acquiring unrestricted control over that shared infrastructure.

Gateway API gives those responsibilities separate resources. The July 13 beta announcement marks GatewayClass, Gateway, and HTTPRoute as v1beta1 in the 0.5.0 release. The milestone matters because the resource model has several implementations and a conformance framework behind it. It does not mean that every proposed routing resource or field has reached the same maturity.

I am interested in this API because Kubernetes is a framework for controllers as much as a collection of built-in workload types. Networking benefits when the resource model expresses operational responsibility directly. A common routing syntax is useful, but the rules governing who can attach a route to shared infrastructure are equally important.

The resource split expresses different decisions

The API overview shipped with 0.5.0 describes infrastructure providers, cluster operators, and application developers as its primary roles. Its objects support that separation without requiring every installation to assign each role to a different person.

GatewayClass describes gateways with shared configuration and behaviour. It is cluster scoped and associated with a controller. A class identifies an implementation contract that Gateways can request. This is a different concern from selecting the backend for an application's HTTP path.

Gateway describes a traffic entry point and its listeners. The underlying implementation might use a cloud load balancer or a proxy. The resource expresses the requested gateway configuration while allowing a controller to supply implementation-specific details. An application can refer to that Gateway without specifying every infrastructure property itself.

HTTPRoute describes how HTTP requests map to backends. It can express request matching and routing behaviour at the application level. Separating that object from Gateway allows multiple application owners to share listeners while maintaining their own route definitions.

These objects participate in one traffic arrangement, but they do not have identical scope or authority. The separation lets an organization choose whether one owner manages everything or whether responsibilities are distributed. It also gives permissions a meaningful set of resources to operate on.

Attachment requires agreement from both sides

A Route requests attachment using its parent references. That is only one side of the relationship. At least one listener on the referenced Gateway must permit the attachment. The route author cannot make an arbitrary Gateway accept configuration solely by naming it.

The tagged API overview describes controls for route kinds, namespace selection, and hostname overlap. A Gateway listener can restrict the namespaces whose Routes it accepts. It can also limit compatible kinds. Where the listener declares a hostname, a Route's hostnames need an appropriate overlap.

This arrangement is useful for shared infrastructure. An operator can allow a selected set of namespaces to attach application routes without transferring ownership of the Gateway. Application owners can then update their own resources within the listener's stated boundaries.

A same-namespace HTTPRoute can request attachment to a Gateway named shared-web through this fragment:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: catalog
spec:
  parentRefs:
    - name: shared-web
  hostnames:
    - catalog.example.com
  rules:
    - backendRefs:
        - name: catalog
          port: 8080

This example assumes the Gateway and Service exist and that the listener permits the relationship. It does not create either resource or install an implementation. Its purpose is to show that the application route refers to gateway infrastructure instead of reproducing that infrastructure's configuration.

Cross-namespace attachment makes the permission boundary more visible. The route can name a Gateway in another namespace, but that Gateway needs to allow attachment from the route's namespace. Kubernetes RBAC governs who can modify the objects, while the attachment rules govern which object relationships are acceptable.

Those mechanisms address different questions. Permission to create a Route does not necessarily grant permission to attach it to every listener. Keeping the relationship explicit makes the shared gateway's exposure policy understandable from the configuration that owns it.

Beta applies to named resources and fields

The announcement's graduation list is specific. GatewayClass, Gateway, and HTTPRoute reach v1beta1. TCPRoute, UDPRoute, and TLSRoute remain part of the work needed to mature layer-four routing. Describing the entire API as uniformly beta would conceal that difference.

The release also introduces standard and experimental channels. Standard contains resources that have reached beta and fields that have graduated from experimental status. Experimental includes that material plus alpha resources and experimental fields. A channel therefore describes a bundle of resources and fields with a stated stability scope.

This matters when reading an example. The presence of an API group name is insufficient to establish that every field shown is part of the standard channel. The release announcement identifies route attachment by port number, URL rewrites, and path redirects as experimental additions.

An application that uses one of those additions is making a more specific dependency than an application that only uses the standard HTTPRoute fields. The distinction should remain visible in implementation support information and deployment configuration. Otherwise, a broadly stated dependency on Gateway API hides the actual feature requirement.

My preference is to preserve that detail when discussing portability. Two implementations can both implement Gateway API while supporting different experimental extensions. A portable resource model needs a defined set of behaviour to which implementations can be compared.

Conformance gives the milestone practical content

The beta announcement lists graduation criteria beyond the existence of a version string. The API has multiple implementations, its resources have basic conformance coverage, and multiple implementations pass tests. SIG Network API reviewers also approved the graduation.

Those criteria give users evidence about agreement on behaviour. A common YAML shape is useful only if different controllers interpret its important fields consistently. Conformance tests provide a way to make parts of that agreement executable.

Basic coverage is still a bounded claim. It does not establish that every extension or every operational property of every gateway implementation is identical. Capacity, provisioning behaviour, and implementation-specific integrations remain relevant choices outside the common API definition.

The Kubernetes announcement also makes clear that no Gateway API implementation is built into Kubernetes. The resources use CustomResourceDefinitions that must be installed, and a controller must reconcile them. Installing the schema alone does not create a functioning gateway.

That deployment model follows Kubernetes' extension architecture. The cluster stores intent through its API, and an implementation acts on that intent. The difference between an accepted object and a working data plane remains a meaningful operational boundary.

Mesh work is beginning under GAMMA

The same release announces the GAMMA initiative, a workstream exploring Gateway API for mesh management and administration. Representatives from several service mesh projects are participating. The immediate work includes exploring service-to-service traffic and developing enhancement proposals.

This is a direction for the API, not a declaration that all service mesh configuration now fits its beta resources. The announcement says authentication and authorization policy are areas for continued work. Those capabilities should remain described as planned exploration at this date.

The overlap is understandable. Gateways and meshes both need ways to express routing relationships, while their deployment and security models can differ. Reusing a resource where the semantics fit could reduce duplicate configuration systems. Forcing unrelated semantics into one object would create a different portability problem.

The tagged API overview already notes that Gateway traffic need not originate outside a cluster. That makes internal use conceptually possible without proving that every mesh use case is solved. GAMMA supplies a place to examine the remaining differences through proposals.

The present milestone is consequently concrete and limited. Three core resources reach beta, the release channels distinguish mature and experimental configuration, and attachment rules make shared ownership explicit. An organization can select an implementation and use those resources while retaining separate decisions about experimental routing behaviour and future mesh support.

Shared infrastructure does not require shared release timing

The resource relationships also permit a Gateway to carry several Routes and a Route to attach to more than one Gateway. The tagged overview describes both patterns. This gives the ownership split practical consequences beyond arranging manifests into different files.

Several applications can share infrastructure while changing their routing definitions independently, within the listener's attachment policy. Conversely, one application route can describe exposure through multiple gateways. That avoids requiring the route's owner to duplicate the application-level decision merely because traffic arrives through more than one entry point.

These relationships still need a compatible implementation and nonconflicting configuration. Their benefit is the explicit model for expressing shared or repeated exposure. Gateway ownership and application route ownership can follow different administrative boundaries without making those relationships implicit in a controller-specific convention.