Support for Gateway API (Gateway, HTTPRoute, etc.) as an alternative to Ingress

[Momotoculteur]

Is your feature request related to a problem? Please describe

Hello team,

The Kubernetes Gateway API is increasingly becoming the new standard for managing incoming traffic, and many platforms are beginning to move away from traditional Ingress resources in favor of Gateway, HTTPRoute, TLSRoute, and others.

Would it be possible to add native support for these resources in the Jenkins Helm Charts?

Background

Ingress objects are now limited in terms of advanced traffic management, granular rule handling, multi-proxy setups, etc.

The Gateway API provides a more flexible and extensible model and is better integrated with modern controllers (Contour, Istio, GKE Gateway, Envoy Gateway, HAProxy, etc.).

Many other Helm charts already provide either an alternative or a toggle between Ingress and Gateway API.

Proposal

• Add a gatewayApi configuration block similar to the existing ingress block, for example:

gatewayApi:
  enabled: true
  ...

• Generate the required Gateway, HTTPRoute & others needed manifests when gatewayApi.enabled = true.

Benefits

• Aligns the chart with modern Kubernetes networking standards.
• Provides greater flexibility for users relying on advanced traffic controllers.
• Ensures long-term maintainability as Ingress becomes progressively less favored.

Thank you for your work on this chart!
If helpful, I can also propose a PR once the direction is approved.

[timja]

PR Welcome

[vpedosyuk]

Perhaps, a more flexible and easier approach would be to add extraObjects: [] key, e.g.:

1. https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/values.yaml#L709-L734
2. https://github.com/cert-manager/cert-manager/blob/master/deploy/charts/cert-manager/values.yaml#L1478-L1485
3. https://github.com/grafana/helm-charts/blob/main/charts/grafana/values.yaml#L1669-L1693

Because sometimes it's necessary to have Gateway/XListenerSet and HTTPRoute, sometimes it's sufficient to have only HTTPRoute and refer to the existing Gateway.

[Momotoculteur]

I could open a PR for this, but I currently don’t have the bandwidth to work on it.

Regarding the extraObjects approach, it’s a good start, but not ideal in this case. The goal of a Helm chart is to offer the simplest possible configuration for anyone, without requiring detailed knowledge of the underlying deployment. Introducing extra objects would also add complexity around ensuring the correct labels/selectors are applied, which can easily lead to misconfigurations and reduces the value of the abstraction.