Introducing GatewayAPI support for Helm

[localleon]

Closes #11621

Adds Gateway API Support to the Nessie Helm Chart

This PR introduces first-class support for the Kubernetes Gateway API (gateway.networking.k8s.io/v1) as an alternative to the existing Ingress configuration. It includes templating, values, documentation, and tests for generating Gateway and HTTPRoute resources.

Key changes:

• New gatewayApi values section with full customization options for Gateways, listeners, TLS, routes, and backend references.
• Templates for Gateway and HTTPRoute resources, including version detection and strict validation.
• Updated README with usage examples and configuration details.
• Added CI values and Helm unittest coverage for default rendering, override behavior, TLS configuration, and custom parentRefs/backends.
• Minor fixes for template newline trimming.

This enables users to expose Nessie using modern Gateway API controllers such as Envoy Gateway, Istio, Traefik, or Kuma.

[localleon]

@adutra please take a look ;-)

[snazy]

Thanks @localleon !

(Not a full review yet.) I think @adutra 's input would be very helpful :)

[snazy]

@localleon mind signing the CLA?

[localleon]

@localleon mind signing the CLA?

Sure, where do i find instructions on hwo to do it? There's nothing in the CONTRIBUTING.md?

[CLAassistant]

All committers have signed the CLA.

[snazy]

@localleon mind signing the CLA?

Sure, where do i find instructions on hwo to do it? There's nothing in the CONTRIBUTING.md?

You should have seen a link on this PR.

[adutra]

Amazing contribution @localleon, thank you for that!

I left a few comments, but overall the PR looks really solid.

[adutra]

General question: is it common to create the Gateway and HTTPRoute objects in separate namespaces? The chart so far doesn't install anything outside the release namespace, so I was wondering if there is a good reason to open up to multi-namespace installs.

[localleon]

Hey, take a look at the following personas inside the GatewayAPI documentation (https://gateway-api.sigs.k8s.io/)

Gateway's CAN be present in a shared platform namespace e..g when the persona deploying Nessie is a different persona then the one managing the loadbalancing/gateway infrastructure for the cluster.

But you do have a point with this, in the context of the chart this may not really be a valid feature. Mostly operators will deploy the HTTPRoute only or HTTPRoute and Gateway in a single namespace. But maybeeee there's the case where operators need to deploy all application gateways inside the "gateway" namespace e.g. a central platform namespace and their HTTPRoute inside their own app-namespace?

[adutra]

Thanks for the pointers. I see 2 issues here:

1. It seems unlikely that application developers would want to install a cross-namespace Gateway via the Nessie chart. This use case would be mixing personas. Maybe we should restrict Gateway creation via this chart to same-namespace Gateways? Or maybe just don't create any Gateway?
2. it seems there could be cases where the Gateway would be already present (in a shared namespace), and the chart would install just an HTTPRoute binding to it. To support that, we could introduce a new boolean flag, e.g. gatewayApi.gateway.create.

Wdyt?

[adutra]

ct install will fail here unless the cluster has the required CRDs. We may need to modify the GitHub jobs accordingly.

[localleon]

How do you want to resolve this?

[adutra]

I think we could get away by installing the CRDs. The below snippet seems to work:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/standard-install.yaml
helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm --version v1.4.1 -n envoy-gateway --create-namespace

Here is what I suggest: open .github/workflows/ci.yml and modify the Install secrets step as follows:

      - name: Install fixtures
        run: |
          kubectl create namespace nessie-ns
          # Install Gateway API CRDs
          kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/standard-install.yaml
          helm install envoy-gateway oci://docker.io/envoyproxy/gateway-helm -n gateway --create-namespace
          # Install other fixtures
          kubectl apply --namespace nessie-ns $(find helm/nessie/ci/fixtures -name "*.yaml" -exec echo -n "-f {} " \;) 

Then we'd need to modify helm/nessie/ci/gateway-api-values.yaml: gatewayApi.gateway.gatewayClassName should be envoy and gatewayApi.httpRoutes[0].namespace should be nessie-ns.

Wdyt?

But if that's too much we can also just remove the helm/nessie/ci/gateway-api-values.yaml test file.

[localleon]

@adutra please take a look again!

$ helm unittest ./
2025/11/19 09:30:31 found symbolic link in path: /home/lraus/nessie/helm/nessie/LICENSE resolves to /home/lraus/nessie/LICENSE. Contents of linked file included and used

### Chart [ nessie ] ./

 PASS   tests/configmap_test.yaml
 PASS   tests/gateway_api_test.yaml
 PASS   tests/logging_storage_test.yaml
 PASS   tests/logging_test.yaml
 PASS   tests/pdb_test.yaml
 PASS   tests/quantity_test.yaml
 PASS   tests/service_monitor_test.yaml

Charts:      1 passed, 1 total
Test Suites: 7 passed, 7 total
Tests:       61 passed, 61 total
Snapshot:    0 passed, 0 total
Time:        596.957069ms