⎈ Helm Lektion 10/12 ~8 Min. Fortgeschritten

OCI Registry und Helm

Charts als OCI Artifacts speichern.

Lernziele

Nach dieser Lektion kannst du Charts als OCI-Artefakte in eine Container-Registry pushen und von dort installieren — mit helm registry login, helm push und oci://-Referenzen. Du verstehst, was sich gegenüber klassischen Repositories ändert (kein helm repo add, keine index.yaml), welche Vorteile die gemeinsame Infrastruktur mit Container-Images bringt und wo die Einschränkungen liegen.

Das Problem: Zwei Verteilwege für ein Deployment

Dein Deployment besteht aus zwei Artefakten: dem Container-Image und dem Chart, das es ausrollt. Das Image liegt in einer Registry mit Authentifizierung, Replikation, Vulnerability-Scanning und Signaturen. Das Chart liegt — bei klassischem Setup aus Lektion 4 — auf einem separaten HTTP-Server mit eigener index.yaml, eigener Zugriffskontrolle und eigenem Hosting, das jemand betreiben muss. Zwei Systeme für zwei Artefakte, die zusammengehören.

Die Auflösung: Container-Registries sprechen das OCI-Distribution-Protokoll, und das kann mehr als Images transportieren — beliebige Artefakttypen, sofern Client und Registry mitspielen. Helm nutzt das nativ (stabil seit Helm 3.8): Ein Chart wird als OCI-Artefakt gepusht und liegt dann neben den Images in derselben Registry — Harbor, GHCR, ECR, ACR, Artifactory und Co. unterstützen das.

Der komplette Publishing- und Konsum-Zyklus:

# Anmelden wie bei docker login
helm registry login ghcr.io -u USERNAME

# Chart paketieren und pushen
helm package mychart/                      # → mychart-0.2.0.tgz
helm push mychart-0.2.0.tgz oci://ghcr.io/USERNAME/charts

# Konsumieren — ohne repo add, direkt per Referenz
helm show values oci://ghcr.io/USERNAME/charts/mychart --version 0.2.0
helm pull oci://ghcr.io/USERNAME/charts/mychart --version 0.2.0
helm install demo oci://ghcr.io/USERNAME/charts/mychart --version 0.2.0

Zwei Dinge fallen sofort auf. Erstens: kein helm repo add. Eine OCI-Referenz ist selbstbeschreibend wie eine Image-Referenz — Registry, Pfad, Version, fertig. Es gibt keinen lokalen Repo-Cache mehr, der veralten könnte; das gesamte „hast du helm repo update vergessen?”-Problemfeld aus Lektion 4 entfällt.

Zweitens: Die Chart-Version wird zum Tag des OCI-Artefakts. helm push tagt automatisch mit der version aus Chart.yaml — du wählst den Tag nicht frei. Das erzwingt die SemVer-Disziplin von der technischen Seite: ein Chart, eine Version, ein Tag. In Deklarationen funktioniert oci:// überall dort, wo vorher eine Repo-URL stand — etwa als repository in den Dependencies aus Lektion 8 oder in den Source-Definitionen von Argo CD und Flux.

Was du gewinnst: eine Infrastruktur für alle Artefakte

Der eigentliche Gewinn ist organisatorisch: Charts erben den kompletten Betriebsunterbau der Image-Registry.

Zugriffskontrolle: dieselben Accounts, Tokens und Berechtigungsmodelle wie für Images — kein zweites Auth-System, das gepflegt werden will.
Betrieb: Replikation in andere Regionen, Retention-Policies, Garbage Collection, Hochverfügbarkeit — alles, was die Registry für Images ohnehin tut.
Supply-Chain-Security: OCI-Artefakte lassen sich mit cosign signieren und verifizieren — derselbe Signatur-Workflow wie bei Images (cosign sign auf den Chart-Digest, Verifikation per Policy in der Pipeline oder im Cluster-Admission-Controller). Dazu kommen Digest-Pinning und je nach Registry Vulnerability-Scanning der referenzierten Inhalte.
Weniger bewegliche Teile: kein ChartMuseum, kein statischer Webserver, keine index.yaml-Pflege, kein --merge-Unfall.

Deshalb die klare Richtungsaussage: Für neue Setups mit vorhandener Container-Registry sind OCI-Charts der Default. Große öffentliche Anbieter sind denselben Weg gegangen — Bitnami-Charts etwa sind unter oci://registry-1.docker.io/bitnamicharts verfügbar.

Die ehrlichen Einschränkungen

Drei Dinge funktionieren anders oder (noch) schlechter als bei klassischen Repos:

Discovery: helm search repo durchsucht den lokalen Index-Cache — den es bei OCI nicht gibt. Es gibt kein generisches „durchsuche diese OCI-Registry nach Charts” im Helm-CLI; du brauchst die Registry-UI, deren API oder einen Katalog wie Artifact Hub. Für interne Plattformen heißt das: Die Auffindbarkeit der Charts musst du selbst organisieren (Portal, Doku, Namenskonventionen).

Tooling-Gefälle: Das Kern-CLI beherrscht OCI vollständig, aber einzelne Werkzeuge und ältere CI-Integrationen erwarten weiter klassische Repo-URLs. Vor einer Migration lohnt der Check der eigenen Toolchain.

Migrationsaufwand: Bestehende Konsumenten haben Repo-URLs in Pipelines, Chart.yaml-Dependencies und GitOps-Definitionen stehen. Der übliche Weg ist ein Parallelbetrieb — beide Kanäle veröffentlichen, Konsumenten schrittweise umstellen, klassisches Repo mit Ankündigung abschalten.

Praxis: pullen von Docker Hub, pushen zu GHCR

Der Konsum-Teil funktioniert sofort und ohne Account — Bitnami veröffentlicht nach OCI:

# Chart aus einer OCI-Registry inspizieren und holen
helm show chart oci://registry-1.docker.io/bitnamicharts/nginx
helm pull oci://registry-1.docker.io/bitnamicharts/nginx
ls nginx-*.tgz   # ein ganz normales Chart-Archiv

# In einen lokalen Cluster installieren
helm install web oci://registry-1.docker.io/bitnamicharts/nginx
helm list
helm uninstall web

Für den Publishing-Teil brauchst du eine Registry mit Schreibzugriff — mit GitHub-Account bietet sich GHCR an (Personal Access Token mit write:packages als Passwort):

helm create mychart
helm package mychart/

helm registry login ghcr.io -u DEIN_GITHUB_USER
helm push mychart-0.1.0.tgz oci://ghcr.io/DEIN_GITHUB_USER/charts

# Gegenprobe: von dort installieren
helm install demo oci://ghcr.io/DEIN_GITHUB_USER/charts/mychart --version 0.1.0
helm uninstall demo

Schau dir das gepushte Artefakt in der Registry-UI an: Es erscheint als Package neben deinen Images, mit der Chart-Version als Tag — genau die Vereinheitlichung, um die es geht.

Typische Stolperfallen

helm repo add mit einer OCI-URL: Funktioniert nicht — OCI-Referenzen werden direkt benutzt, es gibt kein Repository-Konzept mit Index. Wer das mischt, bekommt verwirrende Fehlermeldungen.

Version vergessen beim Install: Bei klassischen Repos nimmt Helm „neueste laut Index”; bei OCI-Referenzen gehört --version an den Befehl. In CI-Pipelines sowieso Pflicht (Lektion 4) — hier fällt das Fehlen nur schneller auf.

Tag ≠ Chart-Version erwartet: helm push tagt immer mit der Version aus Chart.yaml. Wer „latest”-artige Workflows von Images gewohnt ist, muss umdenken: Der Weg zu einem neuen Tag führt über einen Versions-Bump im Chart.

Such-Workflows ungeprüft migriert: Teams, deren Doku auf helm search repo basiert, verlieren beim Umstieg die Discovery. Ersatz (Registry-Katalog, internes Portal) vor der Migration klären, nicht danach.

Interview-Vorbereitung

Auf „Was bedeutet OCI-Support in Helm?” antwortest du mit dem Infrastruktur-Argument: Charts liegen als OCI-Artefakte in derselben Container-Registry wie die Images und erben deren Auth, Replikation, Scanning und Signing (cosign) — statt eines separaten HTTP-Repos mit index.yaml. Dann der Workflow (registry login, package, push oci://, Install direkt per Referenz mit --version) und als Reife-Signal die Einschränkung: keine eingebaute Suche, Discovery muss anders gelöst werden.

Follow-ups:

„Was ersetzt helm repo add bei OCI?” — nichts; OCI-Referenzen sind selbstbeschreibend, es gibt keinen lokalen Index-Cache mehr.
„Woher kommt der Tag des Chart-Artefakts?” — aus der version in Chart.yaml; helm push setzt ihn automatisch.
„Wie signierst du Charts in einer OCI-Registry?” — mit cosign auf den Artefakt-Digest, verifiziert in Pipeline oder Admission-Controller — derselbe Flow wie bei Images.
„Warum würdest du heute OCI statt ChartMuseum wählen?” — weniger Infrastruktur, ein Berechtigungsmodell für Images und Charts, Supply-Chain-Tooling inklusive; ChartMuseum ist ein zusätzliches System ohne diese Integration.

Zusammenfassung

OCI-Support macht die Container-Registry zum Chart-Repository: helm registry login, helm push auf eine oci://-Referenz, Install direkt von dort — ohne repo add, ohne index.yaml, mit der Chart-Version als Tag. Der Gewinn ist die gemeinsame Infrastruktur mit Images (Auth, Replikation, cosign-Signaturen), der Preis die fehlende eingebaute Discovery. Für neue Setups ist OCI der empfohlene Verteilweg.

Damit hast du alle Bausteine von der Template-Engine bis zur Verteilung beisammen. Die nächste Lektion verdichtet das zu Best Practices: Wie sieht ein Chart aus, das Produktionsbetrieb, Team-Wechsel und CI/CD übersteht?