[ziv-yatzik]

charts/lakefs renders only an Ingress. Anything deployed from it behind kgateway has no route at all — the host falls through to the gateway's wildcard fallback, which in our staging environment is a 302 to /not-found. There is no flag to set today; the chart has no Gateway API template of any kind.

This adds one, gated on kgateway.enabled (default false).

What it renders

The same four objects charts/lakefs-cloud renders for a cloud installation, so a deployment from either chart behaves identically on the gateway:

Object	API	Why it is needed
HTTPRoute	gateway.networking.k8s.io/v1	the route itself: hostnames, / → the lakeFS Service, plus any pathsOverrides
DirectResponse	gateway.kgateway.dev/v1alpha1	403 for /metrics and /_pprof. Not optional — the route references it through an ExtensionRef filter, and it replaces nginx's deny all server-snippet
TrafficPolicy	gateway.kgateway.dev/v1alpha1	streamIdle: 350s and request: 0s. Envoy's default request timeout is 15s, which breaks large uploads
BackendConfigPolicy	gateway.kgateway.dev/v1alpha1	circuit breakers and idleTimeout. Envoy defaults to 1024 connections and a 15s idle timeout, both far too low

An HTTPRoute on its own is not parity with the Ingress it replaces: without the DirectResponse the deployment exposes /metrics and /_pprof, and without the two policies it is rate-limited and timed out well before nginx would have been.

Differences from charts/lakefs-cloud

Same structure and same defaults; three things adapted to this chart's conventions:

• Names come from lakefs.fullname, not fixed strings. The cloud chart is one release per namespace and can hardcode lakefs-plane-route; here several releases can share a namespace.
• Backend is lakefs.fullname on .Values.service.port, not a hardcoded lakefs-service:80.
• pathsOverrides is honoured. ingress.yaml supports sending a path prefix to a different Service, so the route generates a rule per override to match.

hostnames defaults to every host in ingress.hosts, so a deployment that already configures the Ingress needs only kgateway.enabled=true.

Migration safety

ingress.enabled and kgateway.enabled are independent. Enable both and the workload has an Ingress and an HTTPRoute at once — which fleet serves it is then purely a DNS question, and rolling back is a record change rather than a redeploy. That is how we are moving isolakes today.

Testing

• helm lint clean, with and without the flag.
• helm template with kgateway.enabled=false (the default) renders none of the four objects — no behaviour change for existing users.
• With it enabled: all four render, the route's ExtensionRef name matches the rendered DirectResponse, hostnames picks up ingress.hosts, and a pathsOverrides entry produces its own rule ahead of the / catch-all.
• Verified against a real fleet: the equivalent objects from charts/lakefs-cloud are what serve production isolakes today, including the //-in-key S3 path that motivated the TrafficPolicy and path-handling settings.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}