feat(argo-cd): gateway support

[tduverge]

Resolves: #2634

Adding some changes to #2689

Especially :

• Support gateway creation
• Support GKE objects associated to gateway
• Rearrange httproute key paths to be clear that httproute is gateway dependent
• Remove API suffix from key gatewayAPI since it doesn't appear in any other key (like ingress or service)

I've also created a PR on pdrastil branch, you can keep its as you wish.

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.
• My build is green (troubleshooting builds).

[JessieAMorris]

Any news on what is preventing this from being merged? This would be a really nice addition.

[mkilchhofer]

Any news on what is preventing this from being merged? This would be a really nice addition.

I think the community did not yet standardize on a pattern how Gateway API is integrated into arbitrary Helm charts. Just why I did not invest a lot if time into this PR:

• Bitnami Helm charts do not offer Gateway API support for their charts
• It is unclear whether an Application chart should deploy a kind: Gateway resource. From the ideology (of the Gateway API creators), the Gateway resource is maintained by the cluster operators, not the app operators:

  

  Source: https://gateway-api.sigs.k8s.io/

• I think the two points are the reason why, @pdrastil did not get a review either.

[pdrastil]

@mkilchhofer I kept this as a draft for now

1. Gateway API contains breaking changes between beta, 1.0 and 1.1 interfaces
2. Other integrations use mixed versions (external-dns, cert-manager)
3. Some implementations support dynamic Gateway resource provisioning (istio, cilium, contour), some act as static deployment (nginx, traefik)

[stemarks]

I am also in need of this feature, I may implement it myself for the time being until a decision is made.

• It is unclear whether an Application chart should deploy a kind: Gateway resource. From the ideology (of the Gateway API creators), the Gateway resource is maintained by the cluster operators, not the app operators:

My personal view is that the app should only create the HTTPRoute, there will likely only be a single gateway shared between multiple services. However there is argument that if this is the only application that requires gateway then it should be included, or if this is the first application to be deployed, which in a lot of scenarios it is, then a gateway would be good here.

Personally I would plan to deploy ArgoCD and have a chart that deploys my gateway as part of an Argo app then the remote access would work once its up and running. I have multiple apps so need the gateway separated.

I think it would be good to at least implement HTTPRoute now and have the gateway discussion separately.

[tduverge]

Hi.

From my pov, as a GKE user, it's not that clear that gateway should be shared between services. I had a case where a single HTTPRoute with a wrong configuration destroyed all the associated load balancer.

The implematation I made follow the same logic than Ingress for many cloud providers where deploying an Ingress creates a load balancer. This is how it works with the current Ingress already in that chart, and it could be easier to migrate from Ingress to Gateway for users if they can do the same with both.

Moreover, in that PR, the gateway deployment is facultative, as I said in the note there.. This let the ability to anyone to choice what he wants.

Of course, I can separate the gateway if this can accelerate things.