Einführung in Kustomize

Wer Kubernetes-Anwendungen in mehreren Umgebungen betreibt, kennt das Problem: kopierte YAML-Dateien, die sich nur in Kleinigkeiten unterscheiden. Ein Tippfehler in der Staging-Kopie, und das Deployment schlägt fehl. Kustomize löst das ohne Templates, indem es eine gemeinsame Basis mit umgebungsspezifischen Anpassungen kombiniert. Sie sehen anhand eines konkreten Beispiels, wie schnell YAML-Duplikate entstehen und warum Kustomize seit kubectl v1.14 zum Standard-Toolkit gehört.

Die Datei kustomization.yaml ist der Dreh- und Angelpunkt: sie listet Ressourcen, definiert Transformationen und steuert den gesamten Build. Sie erstellen Ihre erste kustomization.yaml, fügen Deployments und Services als Ressourcen hinzu und bauen das Ergebnis mit kustomize build und kubectl apply -k. Am Ende dieses Blocks wissen Sie, wie Kustomize Manifests zusammensetzt und können den Output vor dem Deployment prüfen.

Das Konzept von Base und Overlays trennt gemeinsame Konfiguration von umgebungsspezifischen Anpassungen. Sie legen eine Base mit Deployment, Service und ConfigMap an und erstellen darauf aufbauend Overlays für Dev, Staging und Produktion. Jedes Overlay ändert nur das, was sich unterscheidet: Replica-Anzahl, Ressourcen-Limits oder Namespace. Die Verzeichnisstruktur folgt dabei einer klaren Konvention, die sich direkt in ein Git-Repository übernehmen lässt.

Transformers ändern Ressourcen, ohne die Original-Dateien anzufassen. Sie arbeiten mit commonLabels und commonAnnotations, um Metadaten konsistent über alle Ressourcen zu setzen. Mit namePrefix, nameSuffix und namespace passen Sie Ressourcen-Namen und Ziel-Namespaces pro Umgebung an. Der image-Transformer ersetzt Container-Images und Tags zentral in der kustomization.yaml, statt jedes Deployment einzeln zu editieren.

Zeit, alles zusammenzuführen. Sie deployen eine Anwendung mit einer gemeinsamen Base und separaten Overlays für Dev, Staging und Produktion auf Ihrem eigenen Cluster. Dabei nutzen Sie Transformers für Namespaces, Labels und Image-Tags und verifizieren mit kubectl diff, dass jede Umgebung die richtigen Werte enthält. Am Ende läuft dieselbe Anwendung in drei Varianten auf Ihrem Cluster.