Wenn Terraform nicht mehr ausreicht: Control Planes einführen

In seiner Keynote beim Crossplane Community Day beschrieb Bassam Tabbara, Gründer und CEO von Upbound, treffend die Superkräfte von Kubernetes:

1. „deklarative Verwaltung anhand des gewünschten Zustands“

2. „automatisierte Controller-Logik“, um den gewünschten mit dem tatsächlichen Zustand abzugleichen

Dieses Betriebsmodell ist einer der Gründe, warum wir problemlos Hunderte von Compute Nodes und Tausende von Containern verwalten, ihr Networking steuern, Autoscaling nutzen usw. können.

Ein weiterer Grund ist, dass die deklarative API auf einer sinnvollen Abstraktionsebene arbeitet, die nicht zu kognitiver Überlastung führt. Mit einem Kubernetes Deployment können wir beispielsweise ein Container-Image und die Anzahl der laufenden Replikate definieren. Anschließend übernehmen die Kubernetes Controller Scheduling, Monitoring, Neustarts und mehr.

Das Buch „Cloud Native Infrastructure“ von Justin Garrison und Kris Nova beschreibt „Cloud Native Infrastructure“ als „… Infrastruktur, die hinter sinnvollen Abstraktionen verborgen ist und durch APIs gesteuert von Software verwaltet wird …“. Anschließend erläutert das Buch das Reconciler Pattern – den Kern dieses neuen Paradigmas namens „Control Planes“, das herkömmlichere Infrastructure-as-Code-Tools wie Terraform ablösen soll.

Quelle: Keynote von Bassam Tabbara, die oben erwähnt wurde

Composability – ein Wegbereiter für die skalierbare Cloud-Einführung

Entscheidend ist, dass Control Planes sinnvolle Abstraktionen bieten. Cloud-Plattformen sind riesig und komplex und stellen typischerweise Hunderte von Services bereit, jeweils mit vielen unterschiedlichen Konfigurationen und Einstellungen.

Das ist ein wesentlicher limitierender Faktor bei der Cloud-Einführung. Von Platform- und SRE-Teams wird erwartet, dass sie die Cloud vorantreiben. Doch alle Entwickler so weiterzubilden, dass sie die Cloud optimal nutzen können, ist in der Regel nicht skalierbar. Wenn der „durchschnittliche“ Entwickler auf die Cloud schaut, sieht er möglicherweise Folgendes – viele Bausteine in verschiedenen Größen und Farben:

… und eigentlich will er nur Folgendes, wobei lediglich die Farbe frei wählbar ist:

Die allgemeine Ausrichtung der Cloud-Plattform bedeutet, dass sie für die Mehrheit der Entwickler nicht die passende Abstraktion bietet. Die Kubernetes API abstrahierte Compute Nodes, Container Runtimes wie Docker, Networking und Storage. Dadurch wurde es deutlich einfacher, Anwendungen auf einem Container-Cluster bereitzustellen und zu betreiben.

Composability ist die Fähigkeit, mit Abstraktionen auf niedrigerer Ebene Abstraktionen auf höherer Ebene zu erstellen, und entscheidend, um die Einführung jeder Technologie – einschließlich der Cloud – skalierbar zu machen. Aber verlass dich nicht nur auf mein Wort: Sieh dir an, was Kelsey Hightower über Crossplane und Composability sagt.

Terraform entwachsen

Im Kontext von Terraform zeigt sich Composability in Form von Modulen. Die Nutzung von Terraform-Modulen ist ein großer Fortschritt, doch letztlich sind sie nur Vorlagen, die all die kleineren Komponenten ausgeben. Die Verwaltung von Plattformen, die aus Modulen bestehen, wird sehr schnell zur Verwaltung dieser kleineren Komponenten – Terraform-Module sind eine sehr undichte Abstraktion!

Die Verwaltung großer monolithischer Infrastrukturen ist mühsam. Häufig wird das gelöst, indem die Infrastruktur in kleinere Blöcke aufgeteilt wird – eine sogenannte „Tiered Architecture“, bei der jeder Block ein eigenständiger Terraform Plan ist und Abhängigkeiten zwischen den Ebenen über „Remote State“ verwaltet werden.

Das ist zwar besser als eine monolithische Architektur, aber wegen der Abhängigkeiten weiterhin fragil und erfordert eine sorgfältige manuelle Orchestrierung der einzelnen Ebenen.

Terraform ist von Grund auf ein Tool, das wir bei Bedarf ausführen, wenn wir unsere Infrastruktur aktualisieren möchten. Die Automatisierung von Terraform erfolgt häufig beispielsweise mit Atlantis, das ein GitOps-/ChatOps-Modell für Terraform einführt. Drift oder die Reparatur fehlerhafter Infrastrukturkomponenten werden damit jedoch nicht abgedeckt. Solche Situationen müssen wir manuell erkennen und Terraform erneut ausführen, da dieses Modell ereignisgesteuert ist und nicht auf einer Control-Plane-Reconciliation-Schleife basiert.

Beim Zugriffskontrollmodell bedeutet GitOps, dass jeder mit Zugriff auf unser Git-Quell-Repository unsere Infrastruktur ändern kann. Wir können nicht anhand der für uns sinnvollen Abstraktion unterscheiden, wer welche Aktionen ausführen darf. Wir könnten versuchen, Identitäten für die Ausführung von Terraform zu entwerfen, etwa IAM-Rollen mit getrennten Berechtigungen. Da dies jedoch auf dem zugrunde liegenden Cloud-Ressourcenmodell basiert, ist es sehr schwierig, es richtig umzusetzen.

Das hängt wiederum damit zusammen, dass Terraform-Module undichte Abstraktionen sind. Stattdessen möchten wir, dass die Zugriffskontrolle über die Abstraktionsebene definiert wird, auf der wir arbeiten. Im Kubernetes-RBAC-Modell geht es um Ressourcen wie Deployments und Pods über verschiedene Namespaces hinweg. Uns ist dabei egal, wie Container auf Compute Nodes geplant oder die Netzwerksegmentierung mit IP-Tables umgesetzt wird.

Sieh dir auch an, was Nic Cope von Upbound über Terraform im Vergleich zu Crossplane sagt – er hat es viel besser formuliert, als ich es könnte.

Die Zurückhaltung gegenüber Veränderungen überwinden

Control Planes zu nutzen bedeutet, Kontrolle abzugeben. Erfahrene SRE-Teams könnten daher zögern, einer Control Plane zu vertrauen. Auch wenn wir noch sehen müssen, wie sich beispielsweise Crossplane im Ernstfall bewährt, werden wir Control Planes letztlich auch für die Cloud einsetzen. Sich nicht von Details ablenken zu lassen, sie stattdessen zu abstrahieren und die „Maschinen“ die Details erledigen zu lassen, ist eine natürliche Entwicklung in der Tech-Welt.

Das haben wir bereits bei Betriebssystemen, Compilern und Container-Plattformen wie Kubernetes erlebt. Da dies die unvermeidliche Entwicklung ist, sollten wir Control Planes annehmen. Falls Crossplane nicht die richtige Balance und Abstraktionsebene findet, wird es die nächste Control Plane tun.

Das mentale Modell von Infrastruktur verändern

Ops- und SRE-Teams fragen sich möglicherweise, „wie sie mit dem Modell der ‚eventual consistency‘ von Control Planes Uptime und Verfügbarkeit sicherstellen können“.

Diese Sorge ist berechtigt und weist auf ein weiteres gängiges Anti-Pattern in heutigen Infrastrukturdesigns hin. Viele Unternehmen verfügen beispielsweise über Kubernetes-Cluster für „dev“, „stage“ und „production“. Wenn wir beispielsweise den gewünschten Zustand des „production“-Clusters ändern: Wie stellen wir sicher, dass unsere Endnutzer nicht erleben, dass unsere Anwendungen ausfallen, während die Control Plane – über die wir bewusst nur sehr wenig Kontrolle haben – den neuen Zustand konsolidiert? Die Sorge ist berechtigt, aber die Frage ist falsch!

Die Sorge entsteht hier daraus, dass unser „production“-Cluster ein Haustier und kein Nutztier ist.

Mit Kubernetes haben wir gelernt, uns von einzelnen Haustier-Servern hin zu austauschbaren Container-Instanzen zu entwickeln. Eigenschaften wie Uptime und Verfügbarkeit wurden dabei von Kubernetes übernommen, indem es mehrere Container orchestriert. Mit Blick nach vorn müssen wir lernen, dasselbe Modell auf die gesamte Infrastruktur anzuwenden.

Wir sollten nicht mit einem einzelnen „production“-Cluster planen. Stattdessen sollten wir davon ausgehen, dass wir jederzeit mehrere „production“-Cluster haben können, und dies in unserem Design berücksichtigen – ähnlich wie wir Kubernetes Deployments und Services als selbstverständlich ansehen und die Kubernetes Control Plane alle Komplexitäten bei der Verwaltung einzelner Container sowie der Gesamteigenschaften unserer Anwendung übernehmen lassen.