feat: add gateway-api-crds chart

[networkhermit]

What type of PR is this?

What this PR does / why we need it:

Which issue(s) this PR fixes:

Fixes #1590

Does this PR introduce a user-facing change?:

feat: add gateway-api-crds chart

Summary

• crds only, no validating webhook in the same chart, just as prometheus-operator-crds
• use OCI based repositories (GHCR) as the charts storage, no need to set up gh-pages for chart index
• helm/chart-releaser-action will automatically create chart releases/tags on push: see https://github.com/bikesheddev/gateway-api/releases or https://github.com/prometheus-community/helm-charts/releases for showcase
• helm charts is stored on ghcr packages: see https://github.com/orgs/bikesheddev/packages?repo_name=gateway-api or https://github.com/orgs/prometheus-community/packages?repo_name=helm-charts for showcase
• as crds chart is fairly simple, currently it does not support helm customization to avoid unnecessary complexity and reduce maintaining burden

Inspired by the following great resources:

• https://github.com/helm/chart-releaser-action
• https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus-operator-crds
• https://github.com/kubernetes-sigs/metrics-server/tree/master/charts/metrics-server
• https://github.com/kubernetes/dashboard/tree/master/charts/kubernetes-dashboard

TODO

• if chart releated code is pushed without bumping the chart version, the oci package will be forcefully updated, thus break the tag immutability principle
• currently the latest release (v1.6.0) of helm/chart-releaser-action does not support skip_upload, we can wait for them to release a new version, or just pin the version to commit hash which is used by this pr

Demo usage:

check chart packaging content:

❯ helm pull oci://ghcr.io/bikesheddev/charts/gateway-api-crds --version 0.0.1-alpha3
Pulled: ghcr.io/bikesheddev/charts/gateway-api-crds:0.0.1-alpha3
Digest: sha256:57b6f4554bf1f23d1eba45b44bae83bee778bfc32ac454ead20003a20983b812

❯ tar xvzf gateway-api-crds-0.0.1-alpha3.tgz
gateway-api-crds/Chart.yaml
gateway-api-crds/values.yaml
gateway-api-crds/templates/NOTES.txt
gateway-api-crds/templates/gateway.networking.k8s.io_gatewayclasses.yaml
gateway-api-crds/templates/gateway.networking.k8s.io_gateways.yaml
gateway-api-crds/templates/gateway.networking.k8s.io_httproutes.yaml
gateway-api-crds/templates/gateway.networking.k8s.io_referencegrants.yaml
gateway-api-crds/.helmignore
gateway-api-crds/README.md

install gateway-api-crds:

❯ helm install demo-crd oci://ghcr.io/bikesheddev/charts/gateway-api-crds --version 0.0.1-alpha3
Pulled: ghcr.io/bikesheddev/charts/gateway-api-crds:0.0.1-alpha3
Digest: sha256:57b6f4554bf1f23d1eba45b44bae83bee778bfc32ac454ead20003a20983b812
NAME: demo-crd
LAST DEPLOYED: Mon Apr  8 23:53:37 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
See https://github.com/kubernetes-sigs/gateway-api/tree/main/config/crd/standard

❯ kubectl get crd | grep gateway
gatewayclasses.gateway.networking.k8s.io      2024-04-08T15:53:50Z
gateways.gateway.networking.k8s.io            2024-04-08T15:53:50Z
httproutes.gateway.networking.k8s.io          2024-04-08T15:53:52Z
referencegrants.gateway.networking.k8s.io     2024-04-08T15:53:50Z

❯ helm list
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
demo-crd        default         1               2024-04-08 23:53:37.753943 +0800 CST    deployed        gateway-api-crds-0.0.1-alpha3   1.0.0

uninstall gateway-api-crds:

❯ helm uninstall demo-crd
release "demo-crd" uninstalled

❯ kubectl get crd | grep gateway

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: networkhermit
Once this PR has been reviewed and has the lgtm label, please assign thockin for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @networkhermit. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mikemorris]

If we consider moving forward with this, we should likely include the logic suggested in #2678 as guardrails around safe upgrades.

/cc @robscott

[shaneutt]

This is probably on me for not communicating it very well in the relevant issue, but I was kinda hoping we would have a bit more discussion before we added a Helm chart. To be clear, I'm generally hesitant to add Helm charts here.

That said, I remain open to suggestion. I would like to give this some time to see what others think.

/hold

I would ask that we get this topic on the agenda for an upcoming community sync, as I think it would be good to discuss it there at least a bit.

[robscott]

Hey @networkhermit, thanks for working on this! To clarify, we can't include CRDs directly in a helm chart safely. On the other hand, we would consider including a helm chart that deployed something like a Job that installed CRDs (x-ref #2678). Before we start on a helm chart we really need to solve #2678 though, and that's going to require some additional thought around if/how we deal with transitions between release channels. Sorry for any confusion here, let us know if you're interested in working on #2678 though.

[networkhermit]

This is probably on me for not communicating it very well in the relevant issue, but I was kinda hoping we would have a bit more discussion before we added a Helm chart. To be clear, I'm generally hesitant to add Helm charts here.

That said, I remain open to suggestion. I would like to give this some time to see what others think.

/hold

I would ask that we get this topic on the agenda for an upcoming community sync, as I think it would be good to discuss it there at least a bit.

Never mind. It's only a poc to emulate prometheus-operator-crds like installation process. I did it to see if it can ease the iac/gitops bootstrap (see envoyproxy/gateway#1721 (comment) for an example). It doesn't have to be the official supported method.

Hey @networkhermit, thanks for working on this! To clarify, we can't include CRDs directly in a helm chart safely. On the other hand, we would consider including a helm chart that deployed something like a Job that installed CRDs (x-ref #2678). Before we start on a helm chart we really need to solve #2678 though, and that's going to require some additional thought around if/how we deal with transitions between release channels. Sorry for any confusion here, let us know if you're interested in working on #2678 though.

Well. I think #2678 is not simple as it described. I'm not an expert in Gateway API so I doubt I can handle the complexity and meet all the safety and backwards compatibility guarantees, especially the multiple competing implementations situation.

I'm not sure using a job to bootstrap the gateway api crds is possible before the CNI get ready first. As that is the case to bootstrap cilium to use its gateway api support. I'm testing different implementations to better learn Gateway API.