Request: Any Timeline for Stable (GA) Release of Knative Gateway API Integration?

[asuvabi]

First of all, thank you for all the thoughtful work going into the Gateway API integration. We’ve been following the project closely, and we’re genuinely excited about the direction Knative is taking, especially the alignment with Kubernetes Gateway API.

We’re currently operating on Google Kubernetes Engine (GKE) and using GKE Gateway API with managed internal HTTP(S) load balancers and NEGs. The Knative net-gateway-api implementation fits our architecture beautifully.

Our question -

Is there any rough timeline or expectation for when the net-gateway-api implementation might move toward a stable / GA release?

We understand that open-source roadmaps evolve naturally and that stability requires time and community feedback. We’re not looking for firm commitments—just a sense of whether stability is likely in the nearer or longer term, so that we can plan our production rollout strategy accordingly.

Why we care?

We are preparing to adopt Knative Serving with Spring Boot + GraalVM native images for several microservices. Since we already run GKE Gateway API across our environments, the ability to use Knative with Gateway API rather than deploying a separate ingress—is a perfect match for us. Having clarity on the maturity timeline will help us determine whether we can rely on this integration for production workloads or hold off until it’s marked stable.

[dprotaso]

Short Answer

tl;dr - it depends on the Gateway API upstream promoting features from experimental to standard channel and whether your implementation chooses to support those features. I'm going to guess roughly sometime mid-2026

Long Answer

Hey thanks for the question.

It's slow mainly because we're waiting on upstream Gateway API features.

The main ones are

• ListenerSet https://gateway-api.sigs.k8s.io/geps/gep-1713/
• BackendTLSPolicy - https://gateway-api.sigs.k8s.io/api-types/backendtlspolicy/

Parts of BackendTLSPolicy GA'd this month - but I need to verify what fields are experimental/stable.

This feature is for supporting our system TLS feature (where ingress -> knative workloads hop is encrypted).

ListenerSet is needed since if folks enable HTTP-01 Cert Provisions we need the ability to add many certs to a gateway easily. That's a use case that ListenerSet addresses.

Note - GA'ing the integration doesn't necessarily mean every Gateway API implementation will work with Knative. There is a set of features that we require that are 'extended' that though many implementation might support some might not.

For example I created a 'Knative' conformance profile to be able to test this easily but this will need to expand.

See: https://github.com/knative-extensions/net-gateway-api/blob/main/test/gatewayapi/knative_test.go#L32

Also GKE supports managed Gateways but I don't think they're a good fit for Knative. I did a whole presentation about this and found the time to update and create routes to be extremely long. Also it dropped traffic when performing those operations.

See my presentation @ KubeCon I did last year: https://www.youtube.com/watch?v=6eMplLH3NIw

[asuvabi]

Thanks a lot for taking the time to share such a detailed explanation — really appreciate it.

Your points about ListenerSet, BackendTLSPolicy, and the dependency on upstream Gateway API evolution make perfect sense. It also clarifies why Knative GA is tied not just to Knative work, but to the upstream features moving from experimental → standard → stable.

For our environment specifically, things are fairly simple today:
we only use one Gateway with one HTTP listener on port 80, behind an internal load balancer, and our routes are essentially static. We don’t have dynamic hostnames, TLS automation, or any HTTP-01 cert flows, so ListenerSet doesn’t naturally come into play for us. That’s why Gateway API has been stable in production — we’re not exercising the more complex routing or certificate-heavy scenarios that cause the churn and reprogramming delays you described.

We also deploy infrequently, and whenever we do, we shift traffic to another region before making changes. This means we avoid most of the “dynamic update” windows where underlying Gateway programming delays could surface. Still, your point about GKE managed Gateways being slow to update — and even dropping traffic during config changes — is really important for us to factor in as we evaluate Knative.

We’ve also raised a ticket with Google Support to understand the current state of their Gateway implementation and whether there are any known limitations around Knative integration, slow programming, or update-time traffic behavior. That should give us a clearer picture of what to expect before moving forward.

Thanks again for sharing the talk and the upstream timelines.