DevOps 13 Min Lesezeit

Helm Charts – Kubernetes Package Manager Einführung & Praxis 2026

1. Was sind Helm Charts? – Einführung in den Kubernetes Package Manager

Ein Helm Chart ist im Kern ein strukturiertes Verzeichnis mit Dateien, die ein zusammengehöriges Set an Kubernetes-Ressourcen beschreiben. Vergleichbar mit einem Paket in Betriebssystemen wie Debian (apt) oder Red Hat (yum/dnf) kapselt ein Chart alle für eine Anwendung notwendigen Manifeste, Standardkonfigurationen und Abhängigkeiten. Helm nutzt diese Pakete, um sogenannte Releases in einem Kubernetes-Cluster zu installieren, zu aktualisieren oder zu entfernen.

Die Idee ist bestechend einfach: Anstatt 15 einzelne YAML-Dateien für eine typische Web-Anwendung (Deployment, Service, Ingress, ConfigMap, Secret, HPA, ServiceAccount, NetworkPolicy, PodDisruptionBudget, etc.) separat mit kubectl apply auszurollen, definieren Sie diese einmal in einem Chart und installieren sie mit einem einzigen Befehl: helm install my-release ./my-chart. Änderungen an der Konfiguration werden versioniert, Releases können jederzeit auf eine frühere Version zurückgerollt werden.

Helm wurde ursprünglich von Deis entwickelt und 2015 erstmals vorgestellt. Heute ist das Projekt offiziell CNCF Graduated und wird von einer breiten Community getragen. Die aktuelle Generation – oft als Helm 3.x bezeichnet, mit stabilen Releases bis 2026 – hat viele Kinderkrankheiten der Vorgängerversion abgelegt: Tiller als serverseitige Komponente wurde komplett entfernt, die Sicherheit deutlich erhöht und die Architektur vereinfacht. Helm 3 speichert Release-Informationen nun direkt als Kubernetes Secrets im Cluster, was die Bedienung transparenter macht.

Für Einsteiger ist wichtig zu verstehen, dass Helm drei zentrale Begriffe definiert: Chart (das Paket selbst), Repository (ein Ort, an dem Charts gespeichert und verteilt werden, klassisch als HTTP-Index oder modern als OCI-Registry) und Release (eine konkrete Instanziierung eines Charts in einem Cluster). Ein einzelnes Chart kann beliebig oft als verschiedene Releases installiert werden – etwa eine produktive und eine staging-Variante parallel mit unterschiedlichen Konfigurationen.

2. Helm Architektur und Komponenten verstehen

Die Architektur von Helm 3 ist bewusst schlank gehalten und folgt dem Client-only-Prinzip. Im Gegensatz zu Helm 2 gibt es keine serverseitige Komponente (Tiller) mehr, was die Sicherheitslage grundlegend verbessert. Der helm-CLI-Client kommuniziert direkt mit dem Kubernetes-API-Server und nutzt dabei die kubeconfig-Datei des Nutzers – exakt so, wie Sie es von kubectl kennen.

Die wichtigsten Bestandteile im Überblick:

Wenn Sie helm install ausführen, passiert im Hintergrund Folgendes: Das CLI lädt das Chart (lokal oder aus einem Repo), parst die values.yaml, kombiniert diese mit benutzerdefinierten Werten, rendert die Go-Templates, validiert die resultierenden Kubernetes-Manifeste und schickt sie an den API-Server. Anschließend wird ein Secret mit dem Namen sh.helm.release.v1.<release-name> im Ziel-Namespace angelegt, das den Release-Status enthält.

Für die Template-Verarbeitung nutzt Helm die Go-Template-Engine in Kombination mit sprig-Funktionen (über 70 hilfreiche Helper) und der extra-Bibliothek für erweiterte Funktionen. Diese Kombination ist extrem mächtig, erfordert aber auch eine gewisse Einarbeitung – wir gehen darauf in einem späteren Abschnitt detailliert ein.

3. Helm Installation und CLI-Grundlagen 2026

Die Installation von Helm ist auf allen gängigen Plattformen unkompliziert. Auf Linux/macOS empfiehlt sich die Verwendung des offiziellen Installationsskripts oder eines Paketmanagers. Für Windows-Nutzer stehen Chocolatey, Scoop oder winget zur Verfügung. Achten Sie bei der Installation darauf, eine aktuelle 3.x-Version zu verwenden – idealerweise >= 3.14, da hier viele Sicherheits- und Performance-Verbesserungen einfließen, die 2026 relevant sind.

Installation unter Linux/macOS

# Offizielles Installationsskript (empfohlen)
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

# Alternativ via Homebrew (macOS)
brew install helm

# Verifizierung
helm version --short
# Ausgabe: v3.16.0+g58d6e7f

Installation unter Windows

# Via winget
winget install Helm.Helm

# Via Chocolatey
choco install kubernetes-helm

# Via Scoop
scoop install helm

Nach der Installation sollten Sie die Verbindung zu Ihrem Cluster testen. Helm nutzt die gleiche KUBECONFIG-Umgebungsvariable wie kubectl:

# Cluster-Konnektivität prüfen
kubectl cluster-info
helm list --all-namespaces

# Helm-spezifische Umgebungsvariablen
export HELM_NAMESPACE=production
export HELM_KUBECONTEXT=my-cluster-context

Die wichtigsten CLI-Befehle für den Alltag fasst die folgende Tabelle zusammen. Sie bildet das Fundament für die weitere Arbeit mit Helm und sollte auswendig oder zumindest griffbereit sein:

Befehl Beschreibung Typischer Use-Case
helm create <name> Erstellt ein neues Chart-Skelett Eigenes Chart entwickeln
helm install <name> <chart> Installiert ein Chart als Release Neue Anwendung ausrollen
helm upgrade <name> <chart> Aktualisiert ein bestehendes Release Neue Version deployen
helm rollback <name> <rev> Rollt ein Release auf eine frühere Revision zurück Nach fehlgeschlagenem Deployment
helm uninstall <name> Entfernt ein Release komplett Anwendung stilllegen
helm list Listet alle Releases im Namespace Statusübersicht
helm repo add <name> <url> Fügt ein Chart-Repository hinzu Public Charts einbinden
helm search repo <keyword> Sucht in konfigurierten Repos Passendes Chart finden
helm template <name> <chart> Rendert Templates lokal (kein Deployment) Dry-Run / Validierung
helm lint <chart> Prüft Chart auf Syntax- und Best-Practice-Fehler CI/CD-Pipeline
helm package <chart> Packt ein Chart in ein .tgz-Archiv Veröffentlichung vorbereiten
helm show values <chart> Zeigt konfigurierbare Werte an Konfiguration erkunden

4. Anatomie eines Helm Charts – Verzeichnisstruktur erklärt

Ein Helm Chart folgt einer klar definierten Verzeichnisstruktur. Wenn Sie mit helm create my-app ein neues Chart anlegen, generiert Helm ein vollständiges Skelett, das Sie als Vorlage nutzen können. Das Verständnis dieser Struktur ist essenziell, denn jedes Element erfüllt einen bestimmten Zweck im Template- und Packaging-Prozess.

my-app/
├── Chart.yaml              # Metadaten des Charts (Name, Version, Maintainer)
├── Chart.lock              # Lock-Datei für Abhängigkeiten (automatisch generiert)
├── values.yaml             # Standard-Konfigurationswerte
├── values.schema.json      # Optionale JSON-Schema-Validierung für values
├── LICENSE                 # Lizenzdatei (optional, aber empfohlen)
├── README.md               # Dokumentation für Nutzer des Charts
├── .helmignore             # Ausschluss-Liste für helm package
├── templates/              # Verzeichnis mit Kubernetes-Manifest-Templates
│   ├── deployment.yaml     # Deployment-Manifest als Go-Template
│   ├── service.yaml        # Service-Manifest
│   ├── ingress.yaml        # Ingress-Manifest
│   ├── configmap.yaml      # ConfigMap-Manifest
│   ├── hpa.yaml            # HorizontalPodAutoscaler
│   ├── serviceaccount.yaml # ServiceAccount mit RBAC
│   ├── NOTES.txt           # Wird nach erfolgreicher Installation angezeigt
│   ├── _helpers.tpl        # Wiederverwendbare Template-Snippets
│   └── tests/              # Helm-Test-Ressourcen
│       └── test-connection.yaml
├── charts/                 # Gepackte Abhängigkeiten (z. B. .tgz-Dateien)
└── ci/                     # Optionale CI-Hilfsskripte

Die Datei Chart.yaml ist das Herzstück der Chart-Metadaten. Sie enthält Pflichtfelder wie apiVersion, name und version, aber auch optionale Angaben zu Maintainern, Abhängigkeiten, Keywords und Icon. Ein typisches Beispiel für 2026:

apiVersion: v2
name: my-app
description: Moderne Web-Anwendung als Helm Chart
type: application
version: 1.2.0
appVersion: "2.4.1"
home: https://hostazar.com
sources:
  - https://github.com/example/my-app
keywords:
  - web
  - kubernetes
  - microservice
maintainers:
  - name: hostazar-team
    email: [email protected]
dependencies:
  - name: postgresql
    version: 15.2.0
    repository: https://charts.bitnami.com/bitnami
    condition: postgresql.enabled
  - name: redis
    version: 18.6.0
    repository: https://charts.bitnami.com/bit
  
    
Docker Compose auf dem VPS: Webserver, Datenbank & Reverse Proxy richtig betreiben

  
  

    

      DevOps
      02. June 2026
      10 Min
    

    
Docker Compose auf dem VPS: Webserver, Datenbank & Reverse Proxy richtig betreiben

    
Praxisnaher Guide für Docker Compose auf dem VPS: Webserver, Datenbank, Reverse Proxy, TLS, Backups, Updates und Sicherheit richtig planen und betreiben.

    

      Weiterlesen →
    

  





  
📖 Ähnliche Artikel