Kubernetes Helm Charts 2026: Paketierung, Deployment und Interviewfragen

Kubernetes Helm Charts vereinfachen das Application Deployment durch die Bündelung aller Kubernetes-Ressourcen in einem einzigen, versionierten Artefakt. Helm 3, die aktuelle stabile Version, macht Tiller überflüssig und führt OCI-Registry-Unterstützung ein, wodurch die Chart-Distribution sicherer und standardisierter wird. Dieses Tutorial behandelt die Chart-Erstellung, Templating, Deployment-Strategien und die häufigsten Interviewfragen, die von Hiring-Teams gestellt werden.

Helm Chart Struktur und Komponenten verstehen

Ein Helm Chart ist ein Verzeichnis mit einer vordefinierten Struktur. Der Chart-Name wird zum Verzeichnisnamen, und jede Datei dient einem bestimmten Zweck im Paketierungs- und Deployment-Prozess.

# Chart.yaml
apiVersion: v2
name: my-application
description: A production-ready web application
type: application
version: 1.0.0
appVersion: "2.1.0"
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

Die apiVersion: v2 zeigt Helm 3-Kompatibilität an. Das version-Feld verfolgt Chart-Änderungen, während appVersion die Version der bereitgestellten Anwendung widerspiegelt. Dependencies deklarieren andere Charts, die dieses Chart benötigt, mit optionalen Bedingungen zur Aktivierung oder Deaktivierung.

# values.yaml
replicaCount: 3

image:
  repository: myregistry.io/app
  tag: "2.1.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

postgresql:
  enabled: true
  auth:
    database: appdb

Values definieren Konfigurations-Standardwerte, die Benutzer während der Installation überschreiben können. Die Verschachtelung von Werten unter aussagekräftigen Schlüsseln hält Konfigurationen organisiert und selbstdokumentierend.

Kubernetes Deployments mit Helm Templates erstellen

Helm Templates verwenden Go-Templating mit Sprig-Funktionen, um Kubernetes-Manifeste dynamisch zu generieren. Das {{ .Values }}-Objekt bietet Zugriff auf den Inhalt der values.yaml, während {{ .Release }} Deployment-Metadaten enthält.

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-application.fullname" . }}
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "my-application.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "my-application.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - containerPort: {{ .Values.service.port }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

Die nindent-Funktion fügt Zeilenumbruch und Einrückung hinzu, was für die YAML-Generierung entscheidend ist. Die Verwendung von include mit benannten Templates (definiert in _helpers.tpl) hält Templates DRY und wartbar.

# templates/_helpers.tpl
{{- define "my-application.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}

{{- define "my-application.labels" -}}
helm.sh/chart: {{ include "my-application.chart" . }}
app.kubernetes.io/name: {{ include "my-application.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

Helper-Templates standardisieren Namenskonventionen und Labels über alle Ressourcen hinweg und gewährleisten Konsistenz mit den von Kubernetes empfohlenen Labels.

Helm Chart Dependencies und Subcharts

Komplexe Anwendungen hängen oft von Datenbanken, Caches oder Message Queues ab. Helm Dependencies ermöglichen es, diese als Subcharts einzubetten, die während der Installation automatisch verwaltet werden.

# Update dependencies before packaging
helm dependency update ./my-application

# Build dependencies (creates charts/ directory)
helm dependency build ./my-application

Der Befehl helm dependency update lädt Dependencies in das charts/-Verzeichnis herunter. Bedingte Dependencies verwenden Values, um die Einbindung zu steuern:

# values.yaml
postgresql:
  enabled: true

redis:
  enabled: false

# Chart.yaml
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled
  - name: redis
    version: "19.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: redis.enabled

Dieses Muster ermöglicht umgebungsspezifische Konfigurationen, bei denen Produktion verwaltete Dienste nutzt, während Entwicklung In-Cluster-Datenbanken verwendet.

Helm Charts mit Release Management deployen

Helm verfolgt Deployments als Releases, was versionierte Rollbacks und Upgrades ermöglicht. Jedes Release pflegt eine Historie für Auditing und Wiederherstellung.

# Install a chart with custom values
helm install my-release ./my-application \
  --namespace production \
  --create-namespace \
  --values production-values.yaml \
  --set image.tag=2.1.1

# Upgrade an existing release
helm upgrade my-release ./my-application \
  --namespace production \
  --values production-values.yaml \
  --set image.tag=2.2.0 \
  --atomic \
  --timeout 5m

Das --atomic-Flag stellt sicher, dass fehlgeschlagene Upgrades automatisch zurückgerollt werden. Das --timeout-Flag legt fest, wie lange Helm wartet, bis Ressourcen bereit sind, bevor ein Fehler deklariert wird.

# View release history
helm history my-release -n production

# Rollback to previous revision
helm rollback my-release 2 -n production

# Uninstall a release
helm uninstall my-release -n production --keep-history

Das --keep-history-Flag bewahrt Release-Aufzeichnungen auch nach der Deinstallation, nützlich für Compliance und Debugging.

Helm Chart Testing und Validierungsstrategien

Das Testen von Helm Charts vor dem Deployment fängt Template-Fehler und Konfigurationsprobleme frühzeitig ab. Helm bietet integrierte Tools für Linting und Dry-Run-Tests.

# Lint chart for errors and best practices
helm lint ./my-application

# Render templates locally without deploying
helm template my-release ./my-application \
  --values production-values.yaml \
  > rendered-manifests.yaml

# Dry-run against cluster API
helm install my-release ./my-application \
  --dry-run \
  --debug \
  --namespace production

Der Befehl helm template rendert Manifeste lokal, nützlich für CI-Pipelines, die generiertes YAML validieren. Das --dry-run-Flag sendet Manifeste an den Kubernetes-API-Server zur Validierung, ohne Ressourcen zu erstellen.

# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "my-application.fullname" . }}-test"
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: curl
      image: curlimages/curl:8.7.1
      command: ['curl']
      args: ['{{ include "my-application.fullname" . }}:{{ .Values.service.port }}/health']
  restartPolicy: Never

Helm Hooks mit helm.sh/hook: test werden nach helm test my-release ausgeführt und validieren, dass Deployments nach der Installation korrekt funktionieren.

Fortgeschrittene Helm Templating-Techniken

Produktions-Charts erfordern bedingte Logik, Schleifen und Datentransformation. Sprig-Funktionen erweitern Go-Templates mit Utilities für String-Manipulation, Encoding und Flusskontrolle.

# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "my-application.fullname" . }}-config
data:
  {{- range $key, $value := .Values.config }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}
  
  {{- if .Values.features.enabled }}
  FEATURE_FLAGS: {{ .Values.features.flags | join "," | quote }}
  {{- end }}

# templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "my-application.fullname" . }}-secrets
type: Opaque
data:
  {{- range $key, $value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc }}
  {{- end }}

Die range-Funktion iteriert über Maps und Listen. Die b64enc-Funktion kodiert Werte für Kubernetes Secrets in Base64. Pipe-Operatoren verketten Funktionen zur Datentransformation.

Helm Charts Interviewfragen und Antworten

Technische Interviews testen häufig Helm-Wissen durch konzeptionelle und praktische Fragen. Die folgenden decken die am häufigsten gefragten Themen ab.

Was ist der Unterschied zwischen helm install und helm upgrade --install?

helm install erstellt ein neues Release und schlägt fehl, wenn das Release bereits existiert. helm upgrade --install (mit dem --install-Flag) erstellt ein neues Release, wenn keines existiert, oder aktualisiert es, wenn eines vorhanden ist. CI/CD-Pipelines verwenden typischerweise helm upgrade --install für idempotente Deployments.

Wie werden sensible Daten an Helm Charts übergeben?

Es gibt drei Ansätze: externe Secret-Manager (Vault, AWS Secrets Manager), verschlüsselte Values-Dateien (SOPS, sealed-secrets) oder Kubernetes Secrets, die außerhalb von Helm erstellt und in Templates referenziert werden. Das Speichern von Secrets in Klartext-values.yaml-Dateien, die in die Versionskontrolle committed werden, sollte vermieden werden.

Was sind Helm Hooks und wann sollten sie verwendet werden?

Hooks werden zu bestimmten Zeitpunkten im Release-Lebenszyklus ausgeführt: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback, post-rollback und test. Gängige Anwendungsfälle umfassen Datenbank-Migrationen vor Upgrades, das Senden von Benachrichtigungen nach Deployments oder das Ausführen von Integrationstests.

Wie wird die Chart-Versionierung gehandhabt?

Das version-Feld in Chart.yaml verfolgt Chart-Änderungen unter Verwendung von Semantic Versioning. Das appVersion-Feld verfolgt die Version der bereitgestellten Anwendung. Die version sollte bei jeder Chart-Änderung inkrementiert werden, auch wenn die Anwendungsversion gleich bleibt.

Was ist der Zweck von .helmignore?

Ähnlich wie .gitignore schließt .helmignore Dateien von der Chart-Paketierung aus. Typische Einträge umfassen *.tgz (vermeidet das Paketieren vorheriger Builds), .git/, *.md-Dokumentation, die zur Laufzeit nicht benötigt wird, und CI-Konfigurationsdateien.

Für weitere Kubernetes-Interview-Vorbereitung können die Module Kubernetes Basics und Kubernetes Advanced auf SharpSkill erkundet werden.

Fazit

Praktische Erkenntnisse für die Arbeit mit Helm Charts:

• Charts mit klarer Trennung zwischen Chart.yaml-Metadaten, values.yaml-Standardwerten und dem templates-Verzeichnis mit Kubernetes-Manifesten strukturieren
• Helper-Templates in _helpers.tpl verwenden, um Benennung und Labels über alle Ressourcen hinweg zu standardisieren
• Dependencies über Chart.yaml mit bedingter Aktivierung für umgebungsspezifische Konfigurationen verwalten
• Charts mit helm lint, helm template und helm install --dry-run testen, bevor sie in Produktion deployed werden
• Releases mit aussagekräftigen Namen verfolgen und das --atomic-Flag für automatisches Rollback bei fehlgeschlagenen Upgrades verwenden
• Secrets in externen Managern statt in Klartext-Values-Dateien speichern