Chart Dependencies und Umbrella Charts

Lernziele

Nach dieser Lektion kannst du Chart-Dependencies in Chart.yaml deklarieren, mit helm dependency update auflösen und über den Values-Mechanismus konfigurieren — inklusive condition, alias und global. Du verstehst, was Chart.lock leistet, kennst das Umbrella-Chart-Pattern und kannst seine Trade-offs gegen separate Releases abwägen.

Das Problem: Deine App kommt nicht allein

Deine Anwendung braucht Redis als Cache. Du könntest die Redis-Manifeste in dein Chart kopieren — und ab dann selbst pflegen, patchen und upgraden. Oder du installierst Redis als separates Release — und musst dann dokumentieren, dass vor deiner App erst Redis in der richtigen Konfiguration installiert werden muss. Beides skaliert schlecht.

Helm bietet den dritten Weg: Ein Chart deklariert andere Charts als Dependencies. Beim Install werden die Sub-Charts mitgerendert und im selben Release mitinstalliert — eine Installationseinheit, ein Rollback, eine Versionsklammer.

Dependencies deklarieren und auflösen

Dependencies stehen in Chart.yaml:

dependencies:
  - name: redis
    version: "~21.0.0"
    repository: https://charts.bitnami.com/bitnami
    condition: redis.enabled

version akzeptiert SemVer-Constraints — ~21.0.0 heißt „jede 21.0.x”, ^21.0.0 „jede 21.x”. Hier zahlt sich die SemVer-Disziplin aus Lektion 4 aus: Der Constraint ist nur so verlässlich wie die Versionierung des Herausgebers. repository kann eine HTTP-URL, ein oci://-Verweis oder mit @reponame ein Alias auf ein lokal hinzugefügtes Repository sein; für Charts im selben Git-Repo funktioniert file://../pfad.

Deklarieren allein reicht nicht — die Pakete müssen ins Chart:

helm dependency update mychart/

Das löst die Constraints gegen die Repository-Indizes auf, lädt die .tgz-Archive nach charts/ (das Build-Artefakt-Verzeichnis aus Lektion 2) und schreibt Chart.lock: die exakt aufgelösten Versionen plus Digest. Die Lock-Datei spielt dieselbe Rolle wie package-lock.json in npm — helm dependency build stellt später exakt diesen Stand wieder her, statt Constraints neu aufzulösen. In der CI gehört deshalb build (reproduzierbar) statt update (löst neu auf) in die Pipeline, und Chart.lock gehört ins Git.

Sub-Charts konfigurieren: Namensräume in den Values

Wie konfigurierst du ein Sub-Chart? Über einen Values-Abschnitt, der wie das Sub-Chart heißt:

# values.yaml des Eltern-Charts
redis:
  enabled: true
  architecture: standalone

global:
  imageRegistry: registry.example.com

Alles unter redis: wird dem Sub-Chart als dessen .Values übergeben — das Sub-Chart sieht den Schlüssel architecture, nicht redis.architecture. Drei Mechanismen ergänzen das:

condition schaltet Sub-Charts ab: Steht in der Dependency-Deklaration condition: redis.enabled und ist dieser Value false, wird das Sub-Chart komplett ignoriert. Das ist das Standardmuster für optionale Komponenten — „bring deine eigene Datenbank mit oder nimm die eingebaute”.

alias installiert dasselbe Chart mehrfach unter verschiedenen Namen — etwa zweimal Redis als cache und queue, jeweils mit eigenem Values-Abschnitt.

global ist der einzige Values-Bereich, den alle Charts im Verbund sehen — Eltern wie Sub-Charts, unter .Values.global. Typisch für Querschnittswerte wie eine private Registry oder Umgebungs-Labels. Sparsam einsetzen: Globals koppeln alle Charts aneinander, und das Sub-Chart muss sie explizit unterstützen.

Die Gegenrichtung — Werte aus einem Sub-Chart importieren — leistet import-values in der Dependency-Deklaration; in der Praxis ist es selten nötig und du solltest nur wissen, dass es existiert.

Umbrella Charts: ein Release für das ganze System

Treibt man das Pattern auf die Spitze, entsteht das Umbrella Chart: ein Eltern-Chart, das selbst (fast) keine Templates hat und nur Dependencies bündelt — Frontend, Backend, Worker, Redis — zu einem installierbaren Produkt. helm install shop ./shop-umbrella stellt das komplette System in einer definierten Versionskombination auf.

Die Stärken: eine Installationseinheit für zusammengehörige Komponenten, eine getestete Versionsklammer („Shop 2.4 = Frontend 1.8 + Backend 3.1”), ein gemeinsames Rollback. Ideal, wenn das System als Ganzes ausgeliefert wird — etwa an Kunden oder andere Teams.

Die ehrlichen Kosten: Der Blast Radius wächst — jedes Upgrade fasst potenziell alles an, und ein Rollback rollt immer das ganze System zurück, auch wenn nur eine Komponente kaputt ist. Komponenten lassen sich nicht unabhängig deployen, was schnellen Teams im Weg steht. Und die Values-Datei wird zur tief verschachtelten Sammelstelle aller Komponenten-Configs. Deshalb die gängige Faustregel: Umbrella für Dinge, die wirklich nur gemeinsam releast werden; unabhängige Services als separate Releases — orchestriert über GitOps (Argo CD, Flux), wo eine Application-Definition die Klammer bildet statt eines Charts.

Praxis: Eltern-Chart mit lokaler Dependency

Mit file://-Repositories baust du das komplett lokal und ohne Netz:

helm create webapp
helm create umbrella
rm -rf umbrella/templates/*.yaml umbrella/templates/tests

# Dependency deklarieren
cat >> umbrella/Chart.yaml <<'EOF'
dependencies:
  - name: webapp
    version: 0.1.0
    repository: file://../webapp
    condition: webapp.enabled
EOF

# Sub-Chart konfigurieren
cat >> umbrella/values.yaml <<'EOF'
webapp:
  enabled: true
  replicaCount: 2
EOF

# Auflösen und prüfen
helm dependency update umbrella/
ls umbrella/charts/        # webapp-0.1.0.tgz
cat umbrella/Chart.lock

# Rendern: das Sub-Chart bekommt replicaCount=2
helm template demo ./umbrella | grep -B2 'replicas:'

# condition testen: Sub-Chart abschalten
helm template demo ./umbrella --set webapp.enabled=false

Beim letzten Befehl rendert das Umbrella praktisch nichts mehr — condition hat das Sub-Chart vollständig deaktiviert. Ändere danach testweise webapp/values.yaml und beobachte, dass sich am Umbrella nichts ändert, bis du neu paketierst und helm dependency update ausführst: Dependencies sind eingefrorene Artefakte, keine Live-Verweise.

Typische Stolperfallen

Vergessenes helm dependency update: Du änderst den Versions-Constraint oder das Sub-Chart, aber charts/ enthält noch das alte .tgz — gerendert wird der alte Stand. Symptom: „meine Änderung kommt nicht an”.

Values auf falscher Ebene: replicaCount: 5 auf oberster Ebene der Umbrella-Values konfiguriert das Eltern-Chart, nicht das Sub-Chart. Sub-Chart-Werte müssen unter den Schlüssel mit dem Sub-Chart-Namen (bzw. Alias).

Chart.lock nicht eingecheckt oder CI nutzt update: Dann löst jede Pipeline die Constraints neu auf, und ein frisch veröffentlichtes Sub-Chart ändert dein Deployment ohne Code-Änderung. Lock-Datei committen, in der CI helm dependency build.

Umbrella als Default-Architektur: Wer reflexhaft alles unter ein Umbrella packt, erkauft sich gekoppelte Deployments und Rollbacks. Erst fragen: Wird das wirklich immer zusammen releast?

Interview-Vorbereitung

Die Standardfrage: „Wie bindest du in Helm ein Chart in ein anderes ein?” Antworte entlang des Workflows: Deklaration in Chart.yaml (Name, SemVer-Constraint, Repository), Auflösung per helm dependency update nach charts/ mit Chart.lock für Reproduzierbarkeit, Konfiguration über den gleichnamigen Values-Abschnitt plus condition/alias/global. Schließe mit dem Umbrella-Pattern und seinem zentralen Trade-off — gemeinsame Versionsklammer gegen gemeinsamen Blast Radius.

Follow-ups:

• „Wozu Chart.lock?” — eingefrorene, exakt aufgelöste Dependency-Versionen; dependency build reproduziert sie, update löst neu auf.
• „Wie machst du ein Sub-Chart optional?” — condition in der Deklaration plus Boolean-Value, z. B. redis.enabled.
• „Wie sieht ein Sub-Chart die Values des Eltern-Charts?” — gar nicht, außer dem eigenen Namensabschnitt und global.
• „Umbrella Chart oder separate Releases?” — gemeinsamer Release-Zyklus und atomares Rollback vs. unabhängige Deployments und kleiner Blast Radius; bei unabhängigen Services eher GitOps-Orchestrierung.

Zusammenfassung

Dependencies machen Charts komponierbar: deklariert in Chart.yaml mit SemVer-Constraints, aufgelöst per helm dependency update in charts/, festgeschrieben in Chart.lock. Konfiguriert wird über gleichnamige Values-Abschnitte; condition schaltet Komponenten ab, alias vervielfältigt sie, global teilt Querschnittswerte. Umbrella Charts bündeln ein System zu einem Release — stark als Versionsklammer, teuer beim Blast Radius.

Bisher legt Helm Ressourcen einfach in sinnvoller Reihenfolge an. Manchmal braucht es aber echte Ablaufsteuerung — eine Migration vor dem neuen Deployment. Dafür gibt es Hooks, das Thema der nächsten Lektion.