feat(argo-cd): Add HTTPRoute support for Gateway API

[lexfrei]

Summary

This PR adds Gateway API support to the Argo CD Helm chart, providing a modern alternative to traditional Ingress resources.

Added resources

• HTTPRoute (Gateway API v1) - for HTTP(S) traffic routing
• GRPCRoute (Gateway API v1) - for gRPC traffic routing
• BackendTLSPolicy (v1alpha3, experimental) - for HTTPS backend support
• Comprehensive documentation with examples for all three Gateway API resources

Motivation

Gateway API is the successor to Ingress and is becoming the standard for traffic management in Kubernetes. This addition provides users with a modern, vendor-neutral way to expose Argo CD, aligning with the evolving Kubernetes ecosystem.

Testing

• helm lint - passing
• helm template - all three resources render correctly
• Backwards compatible (disabled by default)
• Experimental disclaimers added in values.yaml

Notes

Experimental Status: Gateway API support is marked as EXPERIMENTAL. Support depends on your Gateway controller implementation. Some controllers may require additional configuration (e.g., BackendTLSPolicy for HTTPS backends). Not all Gateway controllers support BackendTLSPolicy (e.g., Cilium does not yet support it).

AI Disclosure: This code was developed with assistance from Claude (Anthropic AI assistant) but has been carefully reviewed, tested, and validated by the PR author.

---

Checklist:

• I have bumped the chart version according to versioning
• I have updated the documentation according to documentation
• I have updated the chart changelog with all the changes that come with this pull request according to changelog.
• Any new values are backwards compatible and/or have sensible default.
• I have signed off all my commits as required by DCO.
• I have created a separate pull request for each chart according to pull requests
• My build is green (troubleshooting builds).

[mkilchhofer]

Hi @lexfrei
Sorry for the late review. We had already multiple PRs related to Gateway API and our helm charts:

• feat(argo-cd): Add Gateway API support #2689
• feat(argo-cd): gateway support #2965

The thing is that IMO Gateway API is not yet very common and also it lacks the feature where Developers are still able to control TLS settings (those are currently handled on the Gateway resource which is in the hands of a cluster operator). ListenerSet's are still in the design phase:

• Design: support Gateway API's new XListenerSet resource cert-manager/cert-manager#7839

So especially for Argo CD the migration to Gateway API is not very straightforward since we use:

• regular HTTP (but with HTTPS backend).
  For this you have to configure HTTPRoute (v1) + BackendTLSPolicy (v1alpha3)
• gRPC
  I assume we need a kind: GRPCRoute as well?

I'd like to hear other opinions from the maintainer colleagues in this repo like @yu-croco @mbevc1 @tico24 .

But IMHO the best would be to raise the topic first in the upstream project (https://github.com/argoproj/argo-cd) and see what needs to be done and especially what needs to be documented in the Operator manual . My feeling is that not every Gateway API controller will support our default configuration of Argo CD in a similar manner, so it might be that users of the envoy-gateway controller needs additional custom resources like Backends(.gateway.envoyproxy.io).

Update:
I mean adding a conditional resource like you did in this PR is not a big deal, but we should make it clear to our chart users, that this might not be the definitive solution and it is a kind of "experimental feature".

[mbevc1]

I'm inclined to agree with @mkilchhofer . Even though it'd be nice to see Gateway API used, it still seems it might need some time to mature 😄

[lexfrei]

You’re absolutely right — I totally forgot that Argo CD also exposes gRPC, since I don’t use that part myself.
I agree about the Gateway API maturity and adoption — that’s exactly why I’m trying to help push HTTPRoute support where I can.
Got it, you’re absolutely right — I’ll take some time to rework this and come back to it.

[mkilchhofer]

I'd be glad as well if we can offer Gateway API support. I recently searched for a Helm chart "standard" about apps using Gateway API and didn't found much. Used this GitHub query:

".Values"  "kind: HTTPRoute" path:**/*.yaml

At least I found out that Helm prepared the helm create mychart scaffolding command with a HTTPRoute resource:

• feat: add httproute from gateway-api to create chart template helm/helm#12912

I first thought, that this will be only in Helm v4 but it seems that it made it into version 3.19.0:

$ helm version
version.BuildInfo{Version:"v3.19.0", GitCommit:"3d8990f0836691f0229297773f3524598f46bda6", GitTreeState:"clean", GoVersion:"go1.24.7"}

$ helm create my-httproute-app
Creating my-httproute-app

$ tree my-httproute-app/
my-httproute-app/
├── Chart.yaml
├── charts
├── templates
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── hpa.yaml
│   ├── httproute.yaml      # <---- see here
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── service.yaml
│   ├── serviceaccount.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

4 directories, 11 files

So I think we are good to go and we can start iteratively (adding BackendTLSPolicy and GRPCRoute later on).

But: I'd add a note to the documentation that it is experimental:

  httproute:
    # -- Enable HTTPRoute resource for Argo CD server (Gateway API).
    # ADD NOTE HERE
    enabled: false

Something that not all use cases are covered today and also that it is unclear what controllers currently are supporting our case. (might depend on what version of the Gateway API they might implement). Cilium's implementation for example does not support BackendTLSPolicy 😆 :

• CFP: BackendTLSPolicy for Cilium Gateway API and HTTPRoutes cilium/cilium#31352

Update:
Oh and while thinking about what to do with this (nice btw) PR, i quickly migrated my homelab Argo CD over to Gateway API (implemented by the Envoy Gateway project):

• feat(Argo CD): Migrate to Gateway API mkilchhofer/k8s-gitops-services#905

But for my homelab I also don't use the gRPC stuff :)

[lexfrei]

Added in this update

• GRPCRoute (Gateway API v1) - handles gRPC traffic that Argo CD exposes
• BackendTLSPolicy (v1alpha3, experimental) - for HTTPS backend connections
• Documentation in README.md with configuration examples for all three resources

Changes

• All templates now follow the Helm scaffolding pattern (matching helm create output)
• Added experimental disclaimers in values.yaml noting controller-specific limitations
• Updated Chart.yaml changelog to reflect full Gateway API support scope

Testing

• helm lint passes
• helm template verified - all three resources render correctly
• Tested with various configurations

---

@mkilchhofer, you mentioned it would be best to raise this topic in upstream Argo CD and update the Operator Manual.

Am I understanding correctly that the plan should be:

1. Create an issue/discussion in argoproj/argo-cd to discuss Gateway API support with upstream maintainers
2. Create a separate PR in argoproj/argo-cd adding Gateway API documentation to the Operator Manual
3. Continue iterating on this Helm chart PR based on feedback from both discussions

Or would you prefer a different approach? You mentioned "we can start iteratively" in your last comment, so I want to make sure I'm aligned with what makes sense for the project.

[mkilchhofer]

@mkilchhofer, you mentioned it would be best to raise this topic in upstream Argo CD and update the Operator Manual.

Am I understanding correctly that the plan should be:

1. Create an issue/discussion in argoproj/argo-cd to discuss Gateway API support with upstream maintainers
2. Create a separate PR in argoproj/argo-cd adding Gateway API documentation to the Operator Manual
3. Continue iterating on this Helm chart PR based on feedback from both discussions

Or would you prefer a different approach? You mentioned "we can start iteratively" in your last comment, so I want to make sure I'm aligned with what makes sense for the project.

What I wanted to say is that we can accept this, even before there is documentation available upstream. But it should be clear that it is currently some kind of experimental.

You did an awesome job, in my opinion we can merge it :)

But we can maybe make sure that documentation also arrive upstream.

[yu-croco]

Thank you for your contribution.