Provide an official Helm chart for Gateway API CRDs

[omerhanegbi]

What would you like to be added:

An officially-maintained Helm chart published by SIG Network that installs the Gateway API CRDs (standard and experimental channels), versioned in lockstep with the existing release artifacts. Distribution model similar to karpenter-crd, cert-manager (installCRDs), or kube-prometheus-stack's CRD sub-chart — CRDs in templates/ with helm.sh/resource-policy: keep, supporting helm upgrade for schema updates.

This would supplement, not replace, the existing kubectl apply -f .../standard-install.yaml flow. Both distribution paths would remain supported.

Why this is needed:

The CRD Management guide correctly identifies CRDs as cluster-admin-owned infrastructure and asks implementations not to overwrite newer CRD versions they encounter. In practice, the ecosystem today does the opposite of what that guidance intends:

• Most implementation charts (Istio, Traefik, kgateway, NGINX Gateway Fabric, etc.) either bundle their own copy of the CRDs behind a flag or tell users to kubectl apply the upstream YAML out-of-band.
• When a cluster has multiple Gateway API consumers — increasingly common as ambient mesh, AWS LBC Gateway API, and per-tenant gateways coexist — there is no Helm-level coordination over CRD ownership. Whoever applied last wins, silently.
• Users managing clusters via Helm-native tooling (Helmfile, Argo CD with Helm sources, Flux HelmReleases) currently have to special-case Gateway API CRDs as a separate kubectl/raw-manifest step outside their Helm workflow. This is friction that other foundational projects have already solved.
• Several unofficial charts have appeared (e.g. dev2prod-hub/gateway-api-chart, jimangel/unofficial-gateway-api-helm) which demonstrates real demand but fragments the ecosystem and provides no upgrade-path guarantees from SIG Network.

An official chart would:

1. Give implementation charts a single canonical dependency to declare, eliminating the "everyone bundles their own copy" pattern that the CRD Management guide already discourages.
2. Make Helm's release ownership the enforcement mechanism for the "don't overwrite newer versions" rule, instead of relying on implementation authors to remember it.
3. Bring Gateway API in line with the distribution pattern already established by other widely-deployed CRD-driven projects (cert-manager, Karpenter, Prometheus Operator), which cluster operators are already familiar with.
4. Integrate cleanly with GitOps tooling without requiring a parallel raw-manifest pipeline alongside the Helm pipeline.

Prior discussion: #1590 (closed via stale bot, no technical resolution).

Happy to contribute a draft chart and CI integration if there's directional agreement from maintainers.

[youngnick]

You're right, we have discussed this before, and there are many reasons why this hasn't proceeded.

The issue here is upgrades and versioning. Once we add a Helm chart, we also have to handle upgrades, downgrades, and how to safely calculate minimum versions.

To be frank, that is not currently possible in a programmatic way - which is what is required for a Helm chart to be safely installed.

If you are running Gateway API v1.3 Experimental, it is not safe to upgrade to v1.4 Standard, because there could be breaking changes for your installation.

The only time when it is guaranteed to be safe to upgrade Gateway API resources is if you are upgrading from Standard version to Standard version.

Additionally, it is possible (and relatively common) to have multiple Gateway API implementations available in a cluster, that require different Gateway API versions. That also means that it's not safe to have implementations include a dependency on an upstream Helm chart, because you can't guarantee that installing that implementation will not upgrade or downgrade your version in a way that will break your existing cluster.

Lastly, the last time we looked at this, Helm's way of managing this was unable to safely determine CRD versions or apply upgrades safely.

We did also discuss having a simple Job (in #2678) that could programmatically determine if an upgrade was safe, and do it for you if so, but that's been on the back burner for a while, since we are working on further stabilizing the API and making it safer and more common to use the Standard install YAMLs.

Once we have the Standard install YAMLs only including Stable objects, then we might be able to supply a Helm chart for them - which would essentially just be installing the Standard YAMLs, the same as a kubectl apply anyway.

Right now, it's better for users to be making the active choice to install a particular version of Gateway API, which is why implementations either have an opt-in for installing their current version, or require users to install it manually before installing the implementation.

So, thanks for the offer, but the Gateway API community is not ready yet to have a community-managed Helm chart for all of those reasons.

The other Helm charts are risking the same problems, but I can't stop them, unfortunately.

[wpbeckwith]

IIRC cilium and some other projects user an operator that loads the correct CRDs into the cluster. Maybe that would be a better approach to account for all the dynamic nature of upgrades and downgrades.

[youngnick]

We'd really, really prefer not to have to require that people run an operator to get the correct versions in your cluster. As always, it's the edge cases that make this suck.

We're working on cleaning up the definitions for the Standard channel at least, so that they only contain Standard/Stable resources, which should mean that it's safer and simpler to write rules about upgrades. I think that in v1.6, when we are aiming to move TCPRoute and UDPRoute to Standard/Stable, this should be a bit easier.

But that doesn't make the multiple-controllers problem easier to manage either.

Maybe at least providing a library for implementation authors might go some way to making an operator-style thing possible. I'll have more of a think about that.