Training Module

Helm — Paketmanagement für Kubernetes

In diesem 95-Minuten-Modul löst ihr das Problem, das jedem Team spätestens beim dritten Manifest-Set auffällt: kubectl apply -f wendet Dateien an, verwaltet aber keine Version davon – kein Upgrade-Pfad, kein Rollback, keine Vorlage für Umgebungsunterschiede. Genau hier setzt Helm an, der Paketmanager für Kubernetes: Ein Chart ist die Vorlage (ein Paket aus Templates plus Defaults), ein Release eine konkrete, versionierte Installation dieses Charts in einem Cluster, ein Repository die Fundstelle, aus der ein Chart bezogen wird – und die klare Abgrenzung zum bisherigen kubectl apply -f: Kubernetes selbst kennt kein Konzept von “Version 3 dieses Manifest-Sets”, Helm schon. Im zweiten Block seziert ihr die Chart-Struktur selbst – Chart.yaml als Metadaten, values.yaml als Default-Konfiguration, templates/ mit Go-Template-Syntax, die Werte aus values.yaml in echte Kubernetes-Manifeste einsetzt – und prüft mit helm template und helm install –dry-run, was am Ende tatsächlich beim Cluster ankommen würde, bevor auch nur ein Objekt real angelegt wird. Der dritte Block ist reines Lifecycle-Management: helm install, helm upgrade, helm rollback und helm history – ihr installiert, ändert Werte, rollt zurück und lest die komplette Release-Historie nach, mit denselben Werkzeugen, die im Ernstfall ein fehlgeschlagenes Upgrade rückgängig machen. Der vierte Block öffnet den Blick nach außen: helm repo add für ein öffentliches Chart-Repository, ein reales, öffentlich verfügbares Chart installieren und über eigene values anpassen, statt Standard-Manifeste selbst zu schreiben – plus eine kurze konzeptionelle Einordnung von Helm-Hooks (Lifecycle-Ereignisse wie pre-install/post-upgrade) und Chart-Security-Scanning, bewusst ohne eigenes Hands-on zu diesen beiden Punkten. Voraussetzung ist das Modul “Kubernetes Workloads & Konfiguration” – Helm erzeugt am Ende dieselben Deployment-/Service-/ConfigMap-Objekte, die dort bereits bekannt sind, hier wird das Manifest-Grundwissen nicht erneut vermittelt. Die Session läuft vollständig lokal über Minikube (–driver=docker) oder alternativ kind, ohne Cloud-Account und ohne Kostenwirkung.

Academy Briefing vereinbaren

Oder sofort per Mail an kontakt@codecraft.academy

Format

95 Minuten, live (remote oder vor Ort), Input & Hands-on

Teilnehmende

Entwickler:innen und Ops, die eigene und fremde Kubernetes-Anwendungen als versionierte Helm-Releases statt loser Manifeste betreiben wollen

Voraussetzungen

Abgeschlossenes Modul “Kubernetes Workloads & Konfiguration” oder gleichwertige Vorkenntnisse, lauffähige lokale Docker-Umgebung für Minikube oder kind

Warum dieses Training für deine Organisation wirkt

kubectl apply kennt keine Version

Wer Manifeste nur mit kubectl apply -f anwendet, hat keinen eingebauten Weg zurück: kein rollback, keine Release-Historie, keine saubere Trennung zwischen Vorlage und Umgebungswerten. Helm liefert genau das als eigenes Konzept.

Dry-Run vor dem echten Risiko

helm template und helm install –dry-run zeigen das gerenderte Manifest, bevor ein einziges Objekt im Cluster entsteht – der Unterschied zwischen “hoffentlich richtig” und “geprüft richtig”.

Fremde Software wird beherrschbar

Viele verbreitete Open-Source-Anwendungen bringen ein offizielles Helm-Chart mit. Wer values gezielt überschreiben kann, statt fremde YAML-Dateien zu kopieren und von Hand zu patchen, bleibt bei jedem Chart-Update upgradefähig.

Was Teilnehmende mitnehmen

  • Chart, Release und Repository als Grundbegriffe unterscheiden und gegen ein reines kubectl apply -f abgrenzen.
  • Die Chart-Struktur Chart.yaml/values.yaml/templates/ lesen und mit Go-Template-Syntax eigene Werte in Manifeste einsetzen.
  • Mit helm template und helm install –dry-run das gerenderte Ergebnis prüfen, bevor ein Objekt im Cluster entsteht.
  • Ein Chart per helm install installieren, per helm upgrade mit neuen Werten aktualisieren, per helm rollback zurückrollen und die Historie mit helm history nachvollziehen.
  • Ein öffentliches Chart-Repository mit helm repo add einbinden und ein reales Chart über eigene values anpassen, statt Standard-Manifeste nachzubauen.
  • Helm-Hooks (Lifecycle-Ereignisse wie pre-install/post-upgrade) und Chart-Security-Scanning konzeptionell einordnen können.
  • In zwei Hands-on-Blöcken Templating/Dry-Run und das komplette Lifecycle-Management (Install → Upgrade → Rollback → History) selbst durchspielen.

Für wen dieses Modul ideal ist

  • • Entwickler:innen und Ops mit abgeschlossenem Modul “Kubernetes Workloads & Konfiguration” oder gleichwertigen Vorkenntnissen
  • • Alle, die bisher Manifeste manuell kopieren und anpassen, statt sie über values zu parametrisieren
  • • Teams, die vor der ersten produktiven Helm-Nutzung wissen wollen, was ein Rollback tatsächlich zurückdreht – und was nicht

Rahmendaten

  • • Dauer: 95 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo, zwei Hands-on-Blöcke zu Templating/Dry-Run und Lifecycle-Management
  • • Voraussetzungen: abgeschlossenes Modul “Kubernetes Workloads & Konfiguration”, lauffähige lokale Docker-Umgebung, keine Cloud-Kostenwirkung

Modulaufbau & Agenda

  1. Problem & Konzept: Chart, Release, Repository (15 min): warum kubectl apply -f keine Versionierung kennt, und wie Chart (Vorlage), Release (konkrete Installation) und Repository (Fundstelle) das Problem lösen.

  2. Chart-Struktur & Templating (30 min, Hands-on): Chart.yaml, values.yaml, templates/ und Go-Template-Syntax – mit dem Hands-on helm template und helm install –dry-run gegen den eigenen Minikube-/kind-Cluster.

  3. Lifecycle-Management (30 min, Hands-on): helm install, helm upgrade, helm rollback und helm history im vollständigen Durchlauf von der Erstinstallation bis zum gezielten Rollback.

  4. Chart-Repositories & öffentliche Charts (20 min): helm repo add, ein reales, öffentlich verfügbares Chart installieren und über eigene values anpassen, dazu kurz Helm-Hooks und Chart-Security-Scanning konzeptionell, ausdrücklich ohne eigenes Hands-on zu diesen beiden Punkten.

Dieses Modul setzt das Aufbaumodul Kubernetes Workloads & Konfiguration — die Objekte für den Alltag voraus. Deployment, Service, ConfigMap und Secret als Objekte werden dort erklärt und hier als bekannt vorausgesetzt – Helm erzeugt am Ende genau diese Objekte, lehrt aber nicht erneut, was in ihnen steht.

Viele öffentliche Charts legen für ihre Workloads einen eigenen ServiceAccount an oder erwarten RBAC-Rechte, damit Init-Container oder Operator-Komponenten Cluster-Objekte lesen oder schreiben dürfen. Die dafür nötigen Bausteine ServiceAccount/Role/RoleBinding und kubectl auth can-i zur Rechteprüfung sind bereits Thema des Vertiefungsmoduls Kubernetes Administration — RBAC, Node-Betrieb und Cluster-Netzwerk, hier nicht erneut erklärt – nur auf den Helm-Kontext angewendet.

Viele produktive Charts setzen in ihren values eigene resources.requests/ resources.limits. Was diese beiden Felder technisch bedeuten – Scheduler-Einplanung vs. Kubelet-Durchsetzung, die daraus abgeleiteten QoS-Klassen und die Kopplung eines HorizontalPodAutoscaler an requests.cpu – ist bereits Thema des Vertiefungsmoduls Kubernetes Ressourcenmanagement & Autoscaling — Requests, Limits und HorizontalPodAutoscaler. Dieses Modul hier zeigt, wo ihr diese Werte in einem Chart überschreibt, nicht was sie im Cluster bewirken. Wer stattdessen die Networking-, Anwendungsdesign-, Storage- oder Monitoring-Perspektive vertiefen will, findet das in den Schwestermodulen Kubernetes Networking Vertiefung, Kubernetes Anwendungsdesign, Kubernetes Storage und Kubernetes: Monitoring & Troubleshooting.

Was hier NICHT behandelt wird: das Schreiben eigener Kubernetes-Manifeste von Grund auf (Deployment/Service/ ConfigMap/Secret) – das ist bereits Thema von Kubernetes Workloads & Konfiguration und wird hier als bekannt vorausgesetzt. Ebenfalls nicht Thema: Helmfile oder andere Werkzeuge zur Orchestrierung mehrerer Charts/Releases, Umbrella-Charts mit verschachtelten Subcharts, der Betrieb eines eigenen Chart-Repositories (z. B. ChartMuseum oder ein selbst gehosteter OCI-Registry-Endpunkt), die GitOps-Anbindung von Helm-Releases über ArgoCD oder Flux – dafür gibt es einen eigenen, strukturierten Kurs mit Helm-Chart-als-Application-Source-Ausblick: das Aufbaumodul Kubernetes GitOps — Deklaratives Deployment mit ArgoCD (setzt nur “Kubernetes Workloads & Konfiguration” voraus, dieses Modul hier ist dafür empfohlen, aber keine Pflicht); für die strukturierte Flux-Abgrenzung samt Umstiegsszenario gibt es darauf aufbauend das Aufbaumodul Kubernetes GitOps mit Flux — Abgrenzung und Umstieg von ArgoCD –, sowie das Schreiben eigener, fortgeschrittener Sprig- Template-Funktionen als Chart-Autor statt als Chart-Anwender. Alles davon ist ein möglicher eigenständiger Vertiefungskurs, hier bewusst außen vor.

Hands-on Inhalte (Auszug)

Chart-Struktur erkunden

  • Ein eigenes Chart-Gerüst per helm create erzeugen und Chart.yaml, values.yaml sowie templates/ gemeinsam durchgehen
  • Einen Wert in values.yaml ändern und in templates/deployment.yaml die zugehörige Go-Template-Referenz {{ .Values.* }} wiederfinden

Templating & Dry-Run

  • Mit helm template . das vollständig gerenderte Manifest ohne jede Cluster-Verbindung ausgeben lassen
  • Mit helm install –dry-run –debug denselben Render-Schritt gegen den eigenen Minikube-/kind-Cluster validieren lassen, bevor real installiert wird

Lifecycle: Install & Upgrade

  • Das eigene Chart per helm install <release-name> . installieren und mit kubectl get pods verifizieren
  • Einen Wert (z. B. die Replica-Zahl) ändern und per helm upgrade <release-name> . ausrollen

Lifecycle: Rollback & History

  • Mit helm history <release-name> alle bisherigen Revisionen des Release auflisten
  • Mit helm rollback <release-name> <revision> gezielt auf eine frühere, funktionierende Revision zurückrollen und das Ergebnis erneut mit kubectl get pods bestätigen

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit vom ersten Chart bis zum verifizierten Rollback) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Bereit, das Modul zu buchen?

Wir passen die Hands-on-Übung auf euren Erfahrungsstand und eure Zielumgebung an.

Academy Briefing anfragen