In Lektion W1.2 haben Sie die Kladde als Manifeste unter k8s/ beschrieben: ein Deployment für kladde-web, eins für kladde-worker, einen
Service, eine ConfigMap. Das genügt für einen Cluster. Sobald es zwei gibt, einen für dev und einen für prod, beginnt das Kopieren:
anderes Image, andere Zahl an Repliken, andere Grenzen, ein anderer Service-Bus-Namespace. Zwei Ordner mit fast gleichen Dateien laufen
auseinander, und niemand sieht mehr, was absichtlich verschieden ist und was nur vergessen wurde.
Diese Lektion beantwortet eine Frage: Wie bleiben die Manifeste einer Anwendung eine einzige Quelle, auch wenn sie in mehreren Umgebungen mit anderen Werten laufen? Die Antwort in der Kubernetes-Welt heißt meist Helm. Sie bauen das Chart der Kladde, spielen es ein, gehen nach einem Fehler zurück und lernen, ein Chart von anderen zu prüfen, bevor es in Ihren Cluster darf.
Das Problem mit den Kopien
Ein Beispiel aus der Kladde. Das Deployment der Web-App unterscheidet sich zwischen dev und prod an wenigen Stellen:
| Was | dev |
prod |
|---|---|---|
| Repliken | 1 | 3 |
| CPU- und Speichergrenzen | klein | größer |
| Stufe der Protokolle | Debug |
Warning |
| Adresse des Service-Bus-Namespace | sb-kladde-dev |
ein eigener Namespace |
Alles andere, die Probes, der Port, die Labels, der Service, die Identität, ist gleich. Eine Kopie je Umgebung zu pflegen heißt, die gleichen vierzig Zeilen zweimal richtig zu halten. Es gibt zwei Auswege: Vorlagen, in die man Werte einsetzt (Helm), und Patches, die man auf eine gemeinsame Basis legt (Kustomize, am Ende dieser Lektion). Beides nimmt die Kopien weg.