[YUNIKORN-3287] Support Gateway API HTTPRoute in Helm chart

[PoiBlackTea]

Description

This PR introduces first-class support for the Kubernetes Gateway API (HTTPRoute) in the YuniKorn Helm chart, addressing [YUNIKORN-3287].

Key additions:

1. HTTPRoute Template: Added httproute.yaml to deploy an HTTPRoute resource, enabling modern ingress routing to the YuniKorn Web UI.

All features are disabled by default to ensure backward compatibility.

Generated by Antigravity IDE.

Type of change

• Feature

Jira issue

Jira ID : https://issues.apache.org/jira/browse/YUNIKORN-3287

• I have created a Jira issue for this pull request.
• The Jira ID is part of the title of this pull request.

AI Tooling

• The PR includes the phrase "Generated by Antigravity IDE", where Antigravity IDE is the name of the AI tool used.
• My use of AI contributions follows the ASF legal policy.

How has this been tested?

• Helm Template Validation: Verified helm template generates correct HTTPRoute and custom resources based on values.yaml inputs.
• Minikube End-to-End Test:
  • Installed Gateway API CRDs (gateway.networking.k8s.io) and an NGINX Gateway on Minikube.
  • Deployed YuniKorn via helm upgrade with httpRoute.enabled=true and custom hostnames.
  • Used kubectl port-forward to the Gateway service and verified that curl to the YuniKorn Web UI (/) and REST API (/ws/v1/clusters) successfully returned HTTP 200, and rejected invalid hostnames with HTTP 404.

Questions:

• The change needs documentation, a pull request for apache/yunikorn-site repository will be created.
• There is breaking changes for older versions: jira is tagged with release-notes label.
• The licenses files needs to be updated.

[PoiBlackTea]

Hi @wilfred-s @manirajv06
Could you please help review this PR? Thanks

[wilfred-s]

The change looks good except for the extra manifest added. Should not be added.

An extra manifest can always be added if and when it is needed for new features. If we never add experimental things it it will just be a maintenance burden.

[PoiBlackTea]

The change looks good except for the extra manifest added. Should not be added.

An extra manifest can always be added if and when it is needed for new features. If we never add experimental things it it will just be a maintenance burden.

Got it, I've dropped the extraManifests commit. Please take a look. Thanks.

[wilfred-s]

LGTM

[adityadtu5]

why this is configurable, should not it always go to webservice?

[PoiBlackTea]

While it's true that the ultimate destination is always the YuniKorn webservice, the Gateway API's rules offer powerful traffic management features that users might need to configure.

By allowing rules to be overridden, users can leverage advanced Gateway API features, such as:

• URLRewrite / Path redirects (e.g., rewriting /yunikorn to /)

If rules is left empty (which is the default), we automatically generate a default rule that maps all traffic directly to the webservice. This keeps it simple out of the box while preserving the full flexibility of the Gateway API for advanced ingress requirements.

[adityadtu5]

ok, thanks for the clarification