Ein eigenes Helm Chart erstellst du am schnellsten mit dem Befehl helm create, der dir ein vollständiges Gerüst aus Chart.yaml, values.yaml und Templates anlegt. Danach passt du die Werte an deine Anwendung an, prüfst das Ergebnis mit helm template und helm lint und veröffentlichst das fertige Chart in einem Repository, damit andere Teams es installieren können.
Klingt nach vielen Schritten, ist aber in der Praxis ein überschaubarer Weg vom leeren Ordner zum eigenen, wiederverwendbaren Paket für Kubernetes. Wer schon einmal ein fremdes Chart installiert hat, kennt die Bausteine bereits: Chart.yaml, values.yaml, ein Ordner templates. Ein eigenes Chart zu bauen bedeutet nur, diese Bausteine selbst zu füllen.
Ich betreibe Kubernetes-Cluster in Produktion und habe das Kubernetes-Praxisbuch bei Rheinwerk geschrieben. Charts, die ich selbst entwickle, laufen bei mir über GitOps in echten Clustern, nicht nur als Übung. Alle meine Beiträge zu Kubernetes findest du gesammelt auf der Seite Kubernetes.
Der Aufbau eines eigenen Helm Charts: Chart.yaml, values.yaml und Templates
Ein Helm Chart besteht immer aus denselben drei Bausteinen. Die Chart.yaml trägt die Metadaten: Name, Version, Beschreibung, optional Schlagworte und die Adresse des Projekts. Die values.yaml enthält die Standardwerte, mit denen die Templates gefüllt werden, etwa Image-Name, Anzahl der Replicas oder Ressourcenlimits. Im Ordner templates liegen die eigentlichen Kubernetes-Manifeste, aber nicht als fertiges YAML, sondern als Vorlage mit Platzhaltern, die Helm zur Installationszeit auffüllt.
Der Trick dahinter: Helm trennt Konfiguration von Code. Statt in jedem Manifest feste Werte einzutragen, verweist ein Template auf einen Wert aus der values.yaml, zum Beispiel auf die Anzahl der Replicas. Wer das Chart installiert, kann diesen Wert überschreiben, ohne das Template selbst anzufassen. Genau das macht ein Chart wiederverwendbar, egal ob für die eigene Entwicklungsumgebung oder für ein anderes Team im Unternehmen.
Zusätzlich zu diesen drei Kernbestandteilen bringt ein frisch angelegtes Chart noch ein paar Begleitdateien mit: eine .helmignore für Dateien, die beim Packen ausgeschlossen werden sollen, und eine Datei NOTES.txt, die Helm nach der Installation als Hinweistext ausgibt. Beide sind klein, aber in der Praxis nützlich, damit ein Chart für andere Nutzer verständlich bleibt.
Ein eigenes Helm Chart erstellen: helm create Schritt für Schritt
Der Befehl helm create ist der schnellste Einstieg, weil er dir ein funktionierendes Beispiel-Chart erzeugt, das du nur noch anpassen musst, statt bei null anzufangen.
helm create meine-app
Danach liegt in deinem Ordner folgende Struktur:
meine-app/
├── Chart.yaml
├── values.yaml
├── .helmignore
├── charts/
└── templates/
├── deployment.yaml
├── service.yaml
├── ingress.yaml
├── hpa.yaml
├── serviceaccount.yaml
├── NOTES.txt
├── _helpers.tpl
└── tests/
Als Erstes öffnest du die Chart.yaml und trägst die Werte ein, die dein Chart tatsächlich beschreiben: den Namen, eine Beschreibung, sinnvolle Schlagworte, damit dein Chart in einem Repository später auffindbar ist, und die Namen der Personen, die für das Chart zuständig sind. Die Version folgt der semantischen Versionierung, du beginnst also typischerweise bei 0.1.0.
Danach kommt die values.yaml an die Reihe. Das mitgelieferte Beispiel-Chart nutzt Nginx als Platzhalter-Anwendung, du ersetzt Image-Name und Tag durch dein eigenes Image und passt Ressourcen, Replicas und Ports an deine Anwendung an. Wie tief du dabei strukturierst, bleibt dir überlassen: Eine flache Struktur mit einzelnen Schlüsseln auf oberster Ebene ist leicht zu lesen und reicht für kleine Charts, eine verschachtelte Struktur mit Gruppen wie image, service und resources lohnt sich, sobald ein Chart wächst und du zusammengehörige Werte bündeln willst.
Erst zum Schluss gehst du in die Templates. Das mitgelieferte deployment.yaml zeigt bereits, wie ein Wert aus der values.yaml referenziert wird, etwa {{ .Values.replicaCount }} für die Anzahl der Pods. Du musst hier nicht alles neu schreiben: Meistens reicht es, die vorhandenen Platzhalter an deine Anwendung anzupassen und nur dort neue Logik einzubauen, wo dein Fall vom Standardbeispiel abweicht.
Templates schreiben und mit helm template prüfen
Helm-Templates basieren auf der Go-Templating-Sprache und wirken auf den ersten Blick fremd, weil doppelte geschweifte Klammern {{ }} als Platzhalter dienen. Innerhalb dieser Klammern kannst du nicht nur Werte einsetzen, sondern auch Bedingungen und Schleifen schreiben. Ein Beispiel: Ein Deployment-Template kann mit einer If-Bedingung prüfen, ob Autoscaling aktiviert ist, und die Anzahl der Replicas nur dann fest setzen, wenn das nicht der Fall ist.
Neben den Werten aus der values.yaml stehen dir eingebaute Objekte zur Verfügung, etwa .Chart.Name für den Namen deines Charts oder .Release.Name für den Namen der konkreten Installation. Diese Objekte brauchst du zum Beispiel, wenn Ressourcen innerhalb des Clusters eindeutige Namen bekommen müssen.
Wie sich eine Änderung an der values.yaml oder an einem Template auswirkt, siehst du, ohne irgendetwas zu installieren, mit helm template:
helm template meine-app ./meine-app
Der Befehl rendert alle Templates lokal und gibt fertige Kubernetes-Manifeste auf der Konsole aus. So findest du Tippfehler in der Template-Syntax oder falsch gesetzte Einrückungen, bevor Kubernetes überhaupt etwas davon sieht. Ich prüfe bei jedem Chart, an dem ich arbeite, das Ergebnis von helm template gegen das, was ich erwarte, gerade bei Bedingungen und Schleifen, die schnell unübersichtlich werden.
Das Chart mit helm lint gegenchecken
helm template zeigt dir das Ergebnis, findet aber nicht jeden Fehler. Für strukturelle Probleme, etwa eine fehlende Pflichtangabe in der Chart.yaml oder eine values.yaml, die nicht zu den Templates passt, gibt es helm lint.
helm lint ./meine-app
Der Befehl prüft dein Chart gegen eine Reihe von Regeln und meldet Hinweise, Warnungen und Fehler mit Angabe der betroffenen Datei. Eine fehlende Chart-Beschreibung kommt als Warnung zurück, gerendertes YAML, das nicht mehr parsbar ist, als Fehler. Verlässt sich ein Template dagegen auf einen Wert, den es in der values.yaml gar nicht gibt, fällt das hier nicht auf: Helm setzt an der Stelle schlicht nichts ein. Ist ein Wert zwingend nötig, erzwingst du ihn im Template mit der Funktion required. Ich baue helm lint und helm template in jede Pipeline ein, die ein Chart baut oder aktualisiert, denn beide Befehle laufen in Sekunden und fangen genau die Fehler ab, die sonst erst bei der Installation im Cluster auffallen würden.
| Befehl |
Prüft |
Typischer Fund |
helm lint |
Struktur und Metadaten des Charts |
fehlende Chart.yaml-Felder, ungültige values.yaml |
helm template |
gerenderte Manifeste |
falsche Einrückung, fehlerhafte Bedingungen |
helm install --dry-run |
Installation gegen einen echten Cluster, ohne Änderungen zu übernehmen |
Konflikte mit vorhandenen Ressourcen |
Chart packen und in einem Repository veröffentlichen
Ein Chart, das nur lokal in deinem Ordner liegt, kannst du zwar in Git einchecken und direkt ausrollen, doch dabei verlierst du den größten Vorteil: dass andere Teams dein Chart einfach finden und installieren können, ohne deinen Quellcode zu klonen. Dafür braucht es ein Repository.
Zum Verpacken genügt ein Befehl:
helm package ./meine-app
Er erzeugt aus deinem Chart-Ordner ein Archiv, benannt nach Chart-Name und Version, zum Beispiel meine-app-0.1.0.tgz. Dieses Archiv lädst du in ein Helm Repository hoch. Zwei Varianten haben sich durchgesetzt: ein klassisches Chart-Repository wie ChartMuseum, das Charts über eine einfache HTTP-API annimmt und ausliefert, oder eine OCI-kompatible Registry, die dieselbe Infrastruktur nutzt wie deine Container-Images. Für ein Team, das ohnehin schon eine Container-Registry betreibt, ist die zweite Variante meist der geringere Aufwand, weil keine zusätzliche Komponente dazukommt.
| Option |
Vorteil |
Nachteil |
| ChartMuseum |
einfach aufzusetzen, reine Chart-API |
zusätzlicher Dienst, den du selbst betreiben musst |
| OCI-Registry |
nutzt vorhandene Container-Registry mit |
Rechteverwaltung teilt sich mit Images, kann bei manchen Registries eigene Konfiguration brauchen |
Sobald das Repository steht, trägst du es lokal ein und kannst dein Chart wie jedes andere installieren:
helm repo add meine-firma https://charts.beispiel.example
helm repo update
helm install meine-app meine-firma/meine-app
Wichtig für die Praxis: Jede veröffentlichte Version bleibt im Repository erhalten. Wer eine ältere Version braucht, bekommt sie über die Versionsnummer aus der Chart.yaml, nicht über einen zusätzlichen Git-Branch. Das ist der Grund, warum sich eine saubere, fortlaufend hochgezählte Versionsnummer auszahlt, sobald mehr als ein Team dein Chart verwendet.
Häufige Fragen
Wie lege ich ein neues Helm Chart mit helm create an?
Mit helm create <name> legt Helm einen Ordner mit Chart.yaml, values.yaml und einem Templates-Verzeichnis an, das bereits ein funktionierendes Beispiel für ein Deployment, einen Service und optional einen Ingress enthält. Du passt danach nur noch Werte und Templates an deine eigene Anwendung an.
Was muss in der Chart.yaml stehen?
Pflicht sind apiVersion, name und version. Sinnvoll sind zusätzlich eine Beschreibung, Schlagworte, eine Projekt-URL und die zuständigen Maintainer, damit andere dein Chart finden und wissen, wen sie bei Fragen ansprechen können.
Wozu dient helm lint?
helm lint prüft dein Chart auf strukturelle Fehler, etwa fehlende Chart.yaml-Felder oder gerendertes YAML, das nicht mehr parsbar ist, bevor du das Chart überhaupt installierst. Wenn du Pflichtwerte strukturell prüfen lassen willst statt einzeln im Template, legst du neben die values.yaml eine values.schema.json mit einem JSON-Schema; Helm validiert die übergebenen Werte dann bei lint, template und install dagegen. Fehlende Values fängt es nicht ab, die musst du im Template selbst über required absichern. Ich lasse den Befehl bei jeder Änderung an einem Chart automatisch laufen.
Wie veröffentliche ich ein eigenes Chart in einem Repository?
Du packst das Chart mit helm package zu einem Archiv und lädst es in ein Chart-Repository wie ChartMuseum oder in eine OCI-kompatible Registry hoch. Danach fügst du das Repository lokal mit helm repo add hinzu und kannst das Chart wie jedes andere mit helm install verwenden.
Brauche ich für jedes Chart ein eigenes Repository?
Nein. Ein Repository kann beliebig viele Charts und Versionen davon enthalten. In einem Unternehmen reicht meist ein gemeinsames Repository für alle intern entwickelten Charts, ähnlich wie ein gemeinsames Repository für Container-Images.
Wie du weitermachst
Sobald dein Chart läuft, lohnt sich der Blick auf die Grundlagen dahinter: Was genau ein Chart von einem einfachen Kubernetes-Manifest unterscheidet, erklärt Helm Charts erklärt: Pakete für Kubernetes. Wer die YAML-Syntax hinter den Templates noch einmal auffrischen will, findet das in Kubernetes YAML: Manifeste verstehen. Und wenn dein Chart regelmäßig aktualisiert werden soll, gehört das Verpacken und Veröffentlichen in eine automatisierte Pipeline, wie in CI/CD für Kubernetes: die Pipeline beschrieben.
Mein Vorschlag für den Einstieg: Nimm eine kleine eigene Anwendung, führe helm create aus, ersetze das Beispiel-Image durch deins und prüfe jede Änderung mit helm template und helm lint, bevor du installierst. Ausführlich mit allen Beispielen, von der Templating-Syntax bis zum Veröffentlichen im Repository, steht das in Kapitel 9 meines Kubernetes-Praxisbuchs bei Rheinwerk.
