Helm ist der Paketmanager f\u00fcr Kubernetes. Ein Chart b\u00fcndelt Manifeste, Standardwerte und Metadaten zu einer installierbaren Einheit. Wer eigene Anwendungen ausrollt, kommt an eigenen Charts kaum vorbei: Sie machen Deployments wiederholbar, umgebungsabh\u00e4ngig konfigurierbar und versionierbar.<\/p>\n
Ein Helm Chart ist ein Verzeichnis mit einer festen Struktur. Helm rendert daraus Kubernetes-Manifeste und wendet sie auf ein Cluster an. Die Trennung ist bewusst: Templates beschreiben die Form der Ressourcen, Values die ver\u00e4nderlichen Werte. Dieselbe Chart-Version l\u00e4sst sich so in Entwicklung, Staging und Produktion installieren, ohne die Manifeste zu kopieren.<\/p>\n
helm version<\/code>)<\/li>\n- Ein Kubernetes-Cluster zum Testen, zum Beispiel kind oder minikube<\/li>\n
kubectl<\/code>, konfiguriert auf dieses Cluster<\/li>\n<\/ul>\nZum reinen Rendern der Manifeste reicht Helm allein. Ein Cluster brauchst du erst, wenn du installieren oder upgraden willst.<\/p>\n
Ein Chart anlegen<\/h2>\n
Der schnellste Einstieg ist das Ger\u00fcst von Helm selbst:<\/p>\n
helm create meine-app\n<\/code><\/pre>\nDaraus entsteht diese Struktur:<\/p>\n
meine-app\/\n Chart.yaml # Name, Version, Beschreibung\n values.yaml # Standardwerte\n charts\/ # Abh\u00e4ngigkeiten\n templates\/ # Kubernetes-Manifeste als Templates\n deployment.yaml\n service.yaml\n ingress.yaml\n _helpers.tpl # wiederverwendbare Template-Funktionen\n NOTES.txt # Hinweis nach der Installation\n<\/code><\/pre>\nhelm create<\/code> legt ein vollst\u00e4ndiges Beispiel f\u00fcr einen Webdienst an, inklusive Ingress, ServiceAccount und Tests. F\u00fcr ein erstes eigenes Chart ist das hilfreich. Was du nicht brauchst, l\u00f6schst du, statt um leere Dateien herumzubauen.<\/p>\nChart.yaml<\/h2>\n
Die Metadaten stehen in Chart.yaml<\/code>. F\u00fcr Helm 3 ist apiVersion: v2<\/code> Pflicht. version<\/code> ist die Version des Charts nach SemVer, appVersion<\/code> die Version der Anwendung, die das Chart ausrollt. Beides ist unabh\u00e4ngig: Ein Chart kann Version 1.4.0 haben und trotzdem Anwendung 2.3.1 deployen.<\/p>\napiVersion: v2\nname: meine-app\ndescription: Webdienst mit Deployment, Service und Ingress\ntype: application\nversion: 0.1.0\nappVersion: \"1.0.0\"\n<\/code><\/pre>\ntype: application<\/code> markiert ein installierbares Chart. type: library<\/code> ist f\u00fcr Charts gedacht, die nur Hilfs-Templates bereitstellen und nicht selbst installiert werden.<\/p>\nWerte und Templates<\/h2>\n
Alles, was sich zwischen Umgebungen unterscheidet, geh\u00f6rt nach values.yaml<\/code>: Image, Replikas, Ressourcen, Ingress-Host, Feature-Flags. Templates lesen diese Werte \u00fcber .Values<\/code>.<\/p>\n# values.yaml\nreplicaCount: 2\n\nimage:\n repository: ghcr.io\/example\/meine-app\n tag: \"1.0.0\"\n pullPolicy: IfNotPresent\n\nservice:\n type: ClusterIP\n port: 80\n\nresources:\n requests:\n cpu: 100m\n memory: 128Mi\n limits:\n cpu: 500m\n memory: 256Mi\n<\/code><\/pre>\nIm Deployment ziehst du die Werte so hinein:<\/p>\n
apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: {{ include \"meine-app.fullname\" . }}\n labels:\n {{- include \"meine-app.labels\" . | nindent 4 }}\nspec:\n replicas: {{ .Values.replicaCount }}\n selector:\n matchLabels:\n {{- include \"meine-app.selectorLabels\" . | nindent 6 }}\n template:\n metadata:\n labels:\n {{- include \"meine-app.selectorLabels\" . | nindent 8 }}\n spec:\n containers:\n - name: {{ .Chart.Name }}\n image: \"{{ .Values.image.repository }}:{{ .Values.image.tag }}\"\n imagePullPolicy: {{ .Values.image.pullPolicy }}\n ports:\n - name: http\n containerPort: 8080\n resources:\n {{- toYaml .Values.resources | nindent 12 }}\n<\/code><\/pre>\nDrei Stellen lohnen einen zweiten Blick:<\/p>\n
\ninclude<\/code> ruft benannte Templates aus _helpers.tpl<\/code> auf. Namen, Labels und Selektoren sollten dort zentral stehen, damit Deployment und Service dieselben Selektoren verwenden.<\/li>\nnindent<\/code> r\u00fcckt mehrzeilige Bl\u00f6cke korrekt ein. Ohne Einr\u00fcckung wird das gerenderte YAML ung\u00fcltig.<\/li>\ntoYaml<\/code> \u00fcbernimmt verschachtelte Werte wie Resources oder Annotations, ohne sie Feld f\u00fcr Feld nachzubauen.<\/li>\n<\/ul>\nBl\u00f6cke optional machen<\/h2>\n
Nicht jede Installation braucht einen Ingress oder ein PersistentVolume. Optionale Ressourcen steuerst du mit if<\/code>:<\/p>\n{{- if .Values.ingress.enabled }}\napiVersion: networking.k8s.io\/v1\nkind: Ingress\nmetadata:\n name: {{ include \"meine-app.fullname\" . }}\nspec:\n rules:\n - host: {{ .Values.ingress.host | quote }}\n http:\n paths:\n - path: \/\n pathType: Prefix\n backend:\n service:\n name: {{ include \"meine-app.fullname\" . }}\n port:\n number: {{ .Values.service.port }}\n{{- end }}\n<\/code><\/pre>\nDas f\u00fchrende Minus in {{-<\/code> entfernt die Leerzeile davor. Sonst sammeln sich im gerenderten Manifest leere Zeilen, die sp\u00e4ter schwer zu lesen sind.<\/p>\nPr\u00fcfen, bevor etwas im Cluster landet<\/h2>\n
Drei Befehle decken die meisten Fehler ab, bevor ein Release entsteht:<\/p>\n
helm lint meine-app\nhelm template meine-app .\/meine-app\nhelm install meine-app .\/meine-app --dry-run --debug\n<\/code><\/pre>\n\nhelm lint<\/code> pr\u00fcft Struktur, Pflichtfelder und \u00fcbliche Chart-Fehler.<\/li>\nhelm template<\/code> rendert die Manifeste lokal, ganz ohne Cluster. Die Ausgabe geh\u00f6rt in ein Review oder in die CI.<\/li>\nhelm install --dry-run<\/code> geht denselben Weg wie eine echte Installation, wendet aber nichts an. Fehlende Werte und ung\u00fcltiges YAML fallen hier auf.<\/li>\n<\/ul>\nWerte f\u00fcr eine Umgebung \u00fcbergibst du per Datei oder einzeln:<\/p>\n
helm template meine-app .\/meine-app -f values-prod.yaml --set replicaCount=3\n<\/code><\/pre>\n--set<\/code> \u00fcberschreibt Werte aus Dateien. F\u00fcr alles, was l\u00e4nger als ein einzelner Wert ist, ist eine eigene Values-Datei lesbarer.<\/p>\nInstallieren und aktualisieren<\/h2>\nhelm install meine-app .\/meine-app --namespace meine-app --create-namespace\nhelm upgrade meine-app .\/meine-app --namespace meine-app\nhelm rollback meine-app 1 --namespace meine-app\n<\/code><\/pre>\nupgrade<\/code> ist auch der richtige Befehl f\u00fcr die erste Installation, wenn das Release vielleicht schon existiert:<\/p>\nhelm upgrade --install meine-app .\/meine-app --namespace meine-app --create-namespace\n<\/code><\/pre>\nHelm speichert jedes Release als Secret im Ziel-Namespace. Deshalb funktionieren Rollback und History, ohne dass das Chart selbst Zustand h\u00e4lt.<\/p>\n
Abh\u00e4ngigkeiten<\/h2>\n
Charts k\u00f6nnen andere Charts einbinden, etwa eine Datenbank oder einen Ingress-Controller. Die Deklaration steht in Chart.yaml<\/code>:<\/p>\ndependencies:\n - name: postgresql\n version: \"16.x.x\"\n repository: https:\/\/charts.bitnami.com\/bitnami\n condition: postgresql.enabled\n<\/code><\/pre>\nhelm dependency update .\/meine-app\n<\/code><\/pre>\nHelm l\u00e4dt die Abh\u00e4ngigkeit als Archiv nach charts\/<\/code>. Werte des Untercharts adressierst du unter dem Chart-Namen, also postgresql.auth.password<\/code> in der eigenen values.yaml<\/code>. condition<\/code> schaltet die Abh\u00e4ngigkeit ab, wenn du in Produktion eine externe Datenbank nutzt.<\/p>\nPacken und ver\u00f6ffentlichen<\/h2>\n
Ein Chart wird als .tgz<\/code> verteilt:<\/p>\nhelm package .\/meine-app\n<\/code><\/pre>\nEs entsteht meine-app-0.1.0.tgz<\/code>. Der Dateiname setzt sich aus name<\/code> und version<\/code> zusammen. F\u00fcr ein eigenes Repository gen\u00fcgt ein Verzeichnis mit den Paketen und einem Index:<\/p>\nmkdir -p repo\nmv meine-app-0.1.0.tgz repo\/\nhelm repo index repo --url https:\/\/example.com\/charts\n<\/code><\/pre>\nindex.yaml<\/code> ist der Katalog, den helm repo add<\/code> sp\u00e4ter liest. In der Praxis landet dieses Verzeichnis auf einem Webserver, in einer OCI-Registry oder in einem Chart-Museum. OCI ist der Weg, den aktuelle Helm-Versionen bevorzugen:<\/p>\nhelm push meine-app-0.1.0.tgz oci:\/\/ghcr.io\/example\/charts\n<\/code><\/pre>\nWorauf es in der Praxis ankommt<\/h2>\n\n- Keine Umgebungsdaten ins Chart.<\/strong> Hostnamen, Replikas und Ressourcengrenzen bleiben in Values-Dateien au\u00dferhalb des Charts oder in einem \u00dcberschreibungs-Mechanismus wie Helmfile oder Argo CD.<\/li>\n
- Ressourcen immer setzen.<\/strong> Requests und Limits geh\u00f6ren in die Standardwerte, sonst plant der Scheduler blind.<\/li>\n
- Labels zentral halten.<\/strong> Selektoren von Deployment und Service m\u00fcssen \u00fcbereinstimmen. Ein Helper-Template verhindert, dass sie auseinanderlaufen.<\/li>\n
- Version bei jeder \u00c4nderung erh\u00f6hen.<\/strong> Helm behandelt ein Chart mit gleicher Version als dasselbe Paket. Ohne Versionsbump \u00fcberschreibst du ein bereits ver\u00f6ffentlichtes Archiv.<\/li>\n
- Secrets nicht in values.yaml committen.<\/strong> Passw\u00f6rter kommen \u00fcber
--set<\/code>, eine externe Secrets-Datei au\u00dferhalb von Git oder \u00fcber einen Operator wie External Secrets.<\/li>\n- Lint und Template in der CI.<\/strong>
helm lint<\/code> und helm template<\/code> fangen YAML- und Strukturfehler, bevor ein Release gebaut wird.<\/li>\n<\/ul>\nKurzfassung<\/h2>\n
Ein Helm Chart ist ein versioniertes Verzeichnis: Chart.yaml<\/code> beschreibt es, values.yaml<\/code> konfiguriert es, templates\/<\/code> erzeugt die Manifeste. helm create<\/code> liefert das Ger\u00fcst, helm lint<\/code> und helm template<\/code> pr\u00fcfen es, helm upgrade --install<\/code> rollt es aus. Wer Werte, Labels und Versionen sauber trennt, kann dasselbe Chart \u00fcber alle Umgebungen hinweg benutzen.<\/p>\n","protected":false},"excerpt":{"rendered":"Helm ist der Paketmanager f\u00fcr Kubernetes. Ein Chart b\u00fcndelt Manifeste, Standardwerte und Metadaten zu einer installierbaren Einheit. Wer eigene Anwendungen ausrollt, kommt an eigenen Charts kaum vorbei: Sie machen Deployments wiederholbar, umgebungsabh\u00e4ngig konfigurierbar und versionierbar. Was ein Chart eigentlich ist Ein Helm Chart ist ein Verzeichnis mit einer festen Struktur. Helm rendert daraus Kubernetes-Manifeste und […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-6","post","type-post","status-publish","format-standard","hentry","category-allgemein"],"_links":{"self":[{"href":"https:\/\/marcohanisch.de\/index.php?rest_route=\/wp\/v2\/posts\/6","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/marcohanisch.de\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/marcohanisch.de\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/marcohanisch.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6"}],"version-history":[{"count":2,"href":"https:\/\/marcohanisch.de\/index.php?rest_route=\/wp\/v2\/posts\/6\/revisions"}],"predecessor-version":[{"id":8,"href":"https:\/\/marcohanisch.de\/index.php?rest_route=\/wp\/v2\/posts\/6\/revisions\/8"}],"wp:attachment":[{"href":"https:\/\/marcohanisch.de\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/marcohanisch.de\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/marcohanisch.de\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}