Kubernetes Gateway API 0.6.0 Release

What’s New and Important in the Latest Release

Welcome to the first article in our series on Kubernetes Gateway API releases, covering the December 2022 release of v0.6.0. Our goal with this series is not just to rehash the release notes or cover them in full but to highlight major and minor changes we think are important and provide context. This release includes

• ReferenceGrant moving to the standard release channel
• Introduction of GRPCRoute in the experimental release channel
• A new responseHeaderModifier field in Filter Rules
• Multiple architecture build support

Key Kubernetes Gateway API Updates

Release Channels

Since this update includes features moving into the experimental and standard release channels, it’s worth briefly explaining them. Custom Resource Definitions (CRDs), which are how Gateway API defines resource specs that projects can implement, can have Alpha API versions and experimental new fields within an otherwise stable API.

• The experimental release channel includes both Alpha APIs and these experimental fields.
• The standard release channel includes only Beta and GA APIs and standard fields.

Essentially, things in the experimental channel are “use at your own risk,” while both implementing projects and users should feel confident using APIs and fields in the standard channel. In fact, the difference between Beta and GA has been small enough that the project is considering removing the Beta step altogether and simply going straight from Alpha to GA.

ReferenceGrant

This resource goes to Beta and thus into the stable channel. By default, a Gateway implementing the Gateway API can only view routes in its own namespace. The ReferenceGrant resource allows a Gateway to see and attach to routes in other namespaces. I love the idea of this resource as it brings security considerations into the role-oriented model of the Gateway API. Emissary-Ingress and Ambassador Edge Stack pioneered the role-oriented model of deploying an API Gateway but were missing the ability to control what routes could attach to what gateway instances. SIG Storage is picking up the idea of the ReferenceGrant as well. It’s such a great idea that SIG Security is considering taking ownership of it as a new standard for cross-namespace security allowances.

GRPCRoute

I find the new GRPCRoute to be one of the more interesting concepts the Gateway API has produced. gRPC runs over HTTP/2 and thus could be routed using an ordinary HTTPRoute object in Gateway API. So why a special CRD? The argument is that the protocol is popular enough and the interface different enough that a separate spec is deserved to make things more friendly for users. It’s worth reading through the full documentation for the new type, but the part that stands out to me from a user perspective is this section on Cross-Serving:

“Implementations that support GRPCRoute must enforce the uniqueness of hostnames between GRPCRoutes and HTTPRoutes. If a route (A) of type HTTPRoute or GRPCRoute is attached to a Listener, and that listener already has another Route (B) of the other type attached, and the intersection of the hostnames of A and B is non-empty, then the implementation must reject Route A. That is, the implementation must raise an ‘Accepted’ condition with a status of ‘False’ in the corresponding RouteParentStatus.

In general, it is recommended that separate hostnames be used for gRPC and non-gRPC HTTP traffic. This aligns with standard practice in the gRPC community. If, however, it is necessary to serve HTTP and gRPC on the same hostname, with the only differentiator being URI, the user should use HTTPRoute resources for both gRPC and HTTP. This will come at the cost of the improved UX of the GRPCRoute resource.”

I worked as a Platform Engineer at a company using the go-kit microservice framework, which makes it very easy to expose one set of services via multiple transports, which could be HTTP/1.1, gRPC, or even CLI commands. For most of the outward-facing services, we used Edge Stack Mappings for both types of traffic, differentiating by a path. We would have loved to have a better UX of the new resource but changing hostnames to adopt it would have been…operationally challenging and probably not worth the trade-off in time and effort. This feels like an odd restriction, but one I assume was made for good reasons, and now I want to go find the meeting recordings of the conversations around this choice.

Response Header Modification

Gateway API has the concept of filters for HTTPRoutes similar to Ambassador Edge Stack’s Filters. In previous versions, it was possible to modify request headers; this change allows changes to response headers. It’s a small feature that brings the API closer to parity with existing products and thus to user needs.

Multiple Architectures

Another small thing but with AWS, Azure, and GCP all offering ARM-based instances, not to mention Apple Silicon putting ARM architecture in the hands of lots of developers, it’s nice to have native builds!

The Next Kubernetes Gateway API Release

The next release of Kubernetes Gateway API will be 0.7.0, but with the core resources GatewayClass and HTTPRoute being stable, there’s talk of it hitting 1.0 soon. We’ll provide updates when both of those releases happen!