ytt-basiertes Templating ist ein enormer Hebel

Wir haben in unserem Beispiel eine Art umgekehrten Ansatz gewählt: Statt die YAMLs als Ausgangsbasis zu nehmen und Teile durch templatisierbare Elemente zu ersetzen, haben wir eine Generierung aufgebaut, die die finalen YAMLs aus den benötigten Bausteinen zusammensetzt. Auf diese Weise erhalten wir ein mächtiges Werkzeug, was uns viel Copy-Paste-Arbeit bei Änderungen erspart.

Alle zu einem Produkt gehörenden Dateien können mit nur einem kubectl apply-Befehl im Cluster angewendet werden; trotzdem ist die Anwendung der Dateien maximal transparent und man weiß vor der Anwendung exakt, was im Cluster laufen wird. Gleichzeitig bekommen wir durch die Nutzung von Git eine Historisierung und ein Quality-Gate bei Änderungen.

Wir konnten hier das tatsächliche Potenzial dieser Templating-Lösung nur anreißen. Trotzdem sollte recht klar werden, welchen enormen Hebel man mit ihr in der Hand hält. Natürlich können andere Lösungen manche Dinge genauso gut. Die absolute Stärke eines ytt-basierten Templatings nach dieser Bauart ist aber die Universalität und die enorme Vielseitigkeit.

Dazu ein hochaktuelles Beispiel: Bei der Mitigierung der Bedrohung von log4shell half das Templating enorm: In einer Produktions-Umgebung konnten über 970(!) Kubernetes-Deployments mit einem Schlag angepasst und abgesichert werden; wiederholbar und deterministisch. Und das mit nur einer einzigen geänderten Zeile in den Sources.

Ausblick

Wenn wir nun - ausgehend von unserem fiktiven (und rudimentären) Beispiel - einen Blick in die Realität wagen, wird schnell klar, dass viele weitere Anforderungen abgebildet werden müssen. Zum Beispiel:

• mTLS (via Linkerd)
• Ingresses und Network-Policies
• Image-Policies (nur signierte Images in prod)
• Service-Accounts
• Secrets und/oder Secret-Store-Anbindung (Vault)
• Persistenz-Anbindung (Persistent Volumes, S3)
• Backups
• Feature-Toggles (Produkt-Features an-/abschalten)
• Zusätzliche Produktlinien (z. B.: Shop für Custom-Räder)

Dass all diese Funktionen lauffähig und wartbar in das hier gezeigte Beispiel eingeflochten werden können, ist dabei keineswegs ein gewagtes Versprechen, sondern gelebte Praxis. In konkreten Zahlen eines realen Anwendungsfalls bedeutet das:

20 in Kubernetes betriebene Produkte in verschiedenen Umgebungen. Jedes Produkt besteht aus rund 60 Pods plus zusätzlichen Ressourcen wie Ingresses, Service-Accounts, Secrets, Volumes und so weiter.

Das Templating erzeugt außerdem Skripte für das Befüllen von Vault oder das Anlegen der Datenbank-User. Der Code des Beispiel-Repositories kann hier aus Platzgründen nicht vollständig diskutiert werden.

Für Fragen, Anregungen und Kritik steht der Autor gerne über die Kommentarfunktion zur Verfügung.

Jochen R. Meyer arbeitet seit über 15 Jahren in der Softwareentwicklung. In seiner aktuellen Rolle als Software Dev & Ops Engineer kümmert er sich in einem kleinen Team um die CI/CD-Toolchain und vor allem um den reibungslosen Betrieb der Kubernetes-basierten Services und Komponenten.