Die values.yaml eines Charts enthält sinnvolle Standardwerte, aber Dev, Staging und Produktion teilen selten einen Namespace, eine Replikazahl oder einen Konfigurationswert. Diese Anleitung behandelt das Schichten zusätzlicher Values-Dateien pro Umgebung, ohne separate Kopien des Charts selbst zu pflegen. Sie baut auf dem webapp-Chart der vorherigen Anleitung auf.

values.yaml als gemeinsame Basis behalten

Lass alles, was überall identisch sein soll, den App-Namen, das Image-Repository, in values.yaml. Nur umgebungsspezifische Felder gehören in eine Override-Datei:

# values-dev.yaml
namespace: dev
config:
  customHeader: "welcome to dev"

# values-prod.yaml
namespace: prod
replicaCount: 5
config:
  customHeader: "welcome to production"

Eine mit -f übergebene Datei ersetzt values.yaml nicht, sie wird darüber zusammengeführt. values-dev.yaml muss nur namespace und config.customHeader erwähnen; alles andere, appName, image, fällt unverändert aus der Basisdatei durch.

Den Namespace in deinen Templates referenzieren

Füge den Wert hinzu und nutze ihn überall dort, wo ein Manifest seinen Namespace deklarieren muss:

# values.yaml (Standardwert hinzufügen)
namespace: default

# templates/deployment.yaml, templates/service.yaml, templates/configmap.yaml
metadata:
  name: {{ .Values.appName }}
  namespace: {{ .Values.namespace }}

Mit der Values-Datei einer Umgebung installieren

kubectl create namespace dev
kubectl create namespace prod

helm install web-dev ./webapp -f values-dev.yaml -n dev
helm install web-prod ./webapp -f values-prod.yaml -n prod

Hier erledigen zwei verwandte, aber unterschiedliche Dinge ihre Arbeit: -n dev sagt Helm, in welchem Namespace die eigenen Metadaten des Releases gespeichert werden, und metadata.namespace in den Templates sagt Kubernetes, in welchen Namespace jede Ressource kommt. Beide gleich zu halten, das Release liegt im selben Namespace wie das, was es deployt hat, ist gängige Praxis und vermeidet später Verwirrung, wenn du helm list -n dev ausführst und erwartest, alles zu sehen, was dort tatsächlich läuft.

helm list -A
kubectl get all -n dev
kubectl get all -n prod
curl <dev-pod-ip>   # oder kubectl port-forward, gemäß NOTES.txt

Bestätige, dass jede Umgebung ihren eigenen customHeader und ihre eigene Replikazahl zeigt.

Die vollständige Rangfolge

Helm führt Values aus mehreren Quellen zusammen, wobei jede die vorherigen überschreibt:

1. values.yaml, die eigenen Standardwerte des Charts.
2. Die values.yaml eines übergeordneten Charts, wenn dieses Chart als Abhängigkeit genutzt wird (hier nicht behandelt).
3. Jede mit -f übergebene Datei, in der angegebenen Reihenfolge, spätere Dateien gewinnen gegen frühere.
4. --set, --set-string oder --set-json-Flags, die gegen jede Datei gewinnen.

helm upgrade web-dev ./webapp -f values-dev.yaml --set replicaCount=1

--set ist praktisch für eine einmalige Überschreibung oder einen schnellen Test, aber für alles, was du reproduzieren willst, lege es in eine Datei und checke sie in die Versionskontrolle ein. Ein an einem Terminal getipptes --set-Flag hinterlässt keine Aufzeichnung dessen, was tatsächlich deployt wurde.

Zwei Wege, zu prüfen, was ein Merge ergeben hat

Bevor du einer Installation oder einem Upgrade traust, sieh dir das Ergebnis an:

helm template ./webapp -f values-prod.yaml
helm get values web-prod

helm template -f rendert das Chart mit einer gegebenen Values-Datei genau so, wie es die Installation täte, ohne den Cluster anzufassen, sodass du die Ausgabe zweier Umgebungen direkt vergleichen kannst. helm get values (nach der Installation) zeigt die tatsächlich gegen ein Live-Release aufgezeichneten Values, was du prüfst, wenn ein laufendes Release nicht dem entspricht, was eine Datei deiner Erwartung nach erzeugen müsste.

Ein Hinweis zu Secrets

Values-Dateien sind reiner Text, lege also keine echten Zugangsdaten in eine, die in Git committet wird. Eine gängige Aufteilung ist: nicht sensible Konfiguration pro Umgebung in values-<env>.yaml und Secrets entweder per --set aus einem CI-Secret-Store, über ein Werkzeug wie Sealed Secrets oder SOPS einspeisen, oder das Chart auf ein außerhalb von Helm erstelltes Kubernetes-Secret verweisen lassen, statt den Wert überhaupt in values.yaml einzubetten.