What problem are you trying to solve?
Linkerd's Helm charts (linkerd-crds, linkerd-control-plane, and the extension charts) are only distributed through the classic index-based HTTP Helm repository at https://helm.linkerd.io/{stable,edge}. They are not published as OCI artifacts to any registry.
This is increasingly out of step with how charts are consumed today:
- Helm has supported OCI registries natively and enabled-by-default since v3.8. OCI is now the recommended distribution mechanism, and
helm push/helm pull/helm install oci://... are first-class.
- GitOps tooling (Argo CD, Flux) and internal chart mirrors increasingly standardize on
oci:// sources, so consumers currently have to self-mirror the Linkerd charts into their own OCI registry to fit that model.
- OCI distribution comes with content-addressable digests and cosign/Sigstore signing support, which strengthens supply-chain guarantees over an unsigned
index.yaml repo.
Several other CNCF projects have already added OCI publishing for exactly these reasons (e.g. kubernetes-sigs/external-dns#4630, kubernetes/autoscaler#7086).
How should the problem be solved?
Publish the Linkerd charts as OCI artifacts to a registry (e.g. cr.l5d.io alongside the existing images, or ghcr.io/linkerd) as part of the release pipeline, in addition to — not instead of — the existing HTTP repo so nothing breaks for current users.
Concretely:
- On each stable/edge release,
helm push linkerd-crds and linkerd-control-plane (and the extension charts) to the chosen OCI registry.
- Optionally sign the pushed artifacts with cosign.
- Document the
oci:// install path in the "Installing Linkerd with Helm" docs.
Drawbacks / considerations:
- Adds a publishing step and a registry namespace to maintain.
- Two distribution channels to keep in sync (mitigated by driving both from the same release job).
Any alternatives you've considered?
- Self-mirroring (the current workaround): consumers
helm pull from helm.linkerd.io and helm push to their own OCI registry in CI. This works but pushes ongoing maintenance onto every user and defeats the point of an official artifact.
- Staying HTTP-only: functional, but misses digest-pinning/signing and forces the mirror workaround for OCI-first GitOps setups.
How would users interact with this feature?
Install directly from the OCI registry with no helm repo add step:
helm install linkerd-crds oci://cr.l5d.io/linkerd/linkerd-crds \
--version <version> -n linkerd --create-namespace
helm install linkerd-control-plane oci://cr.l5d.io/linkerd/linkerd-control-plane \
--version <version> -n linkerd \
--set-file identityTrustAnchorsPEM=ca.crt \
--set-file identity.issuer.tls.crtPEM=issuer.crt \
--set-file identity.issuer.tls.keyPEM=issuer.key
And reference it directly in Argo CD / Flux sources via oci://.
Would you like to work on this feature?
maybe
What problem are you trying to solve?
Linkerd's Helm charts (
linkerd-crds,linkerd-control-plane, and the extension charts) are only distributed through the classic index-based HTTP Helm repository athttps://helm.linkerd.io/{stable,edge}. They are not published as OCI artifacts to any registry.This is increasingly out of step with how charts are consumed today:
helm push/helm pull/helm install oci://...are first-class.oci://sources, so consumers currently have to self-mirror the Linkerd charts into their own OCI registry to fit that model.index.yamlrepo.Several other CNCF projects have already added OCI publishing for exactly these reasons (e.g. kubernetes-sigs/external-dns#4630, kubernetes/autoscaler#7086).
How should the problem be solved?
Publish the Linkerd charts as OCI artifacts to a registry (e.g.
cr.l5d.ioalongside the existing images, orghcr.io/linkerd) as part of the release pipeline, in addition to — not instead of — the existing HTTP repo so nothing breaks for current users.Concretely:
helm pushlinkerd-crdsandlinkerd-control-plane(and the extension charts) to the chosen OCI registry.oci://install path in the "Installing Linkerd with Helm" docs.Drawbacks / considerations:
Any alternatives you've considered?
helm pullfromhelm.linkerd.ioandhelm pushto their own OCI registry in CI. This works but pushes ongoing maintenance onto every user and defeats the point of an official artifact.How would users interact with this feature?
Install directly from the OCI registry with no
helm repo addstep:And reference it directly in Argo CD / Flux sources via
oci://.Would you like to work on this feature?
maybe