Crossplane ist großartig, aber was ist mit kritischer Infrastruktur?

Was ist Crossplane?

Crossplane ist eine Control Plane, die innerhalb von Kubernetes läuft.

Eine Control Plane bezeichnet als Konzept bzw. Paradigma einen Service, der einen deklarierten Zustand überwacht und sicherstellt, dass der tatsächliche Zustand eines Systems diesem entspricht. Anders ausgedrückt: Eine Control Plane gleicht den aktuellen Zustand eines Systems mit dem gewünschten Zustand ab.

Crossplane wird häufig zur Bereitstellung und Verwaltung von Cloud-Ressourcen eingesetzt. Es stellt sicher, dass die beim Cloud-Provider laufenden Ressourcen mit dem in Kubernetes deklarierten Zustand synchronisiert sind.

Beispielsweise kann ein Entwickler eine Datenbank als Kubernetes-Manifest (YAML) deklarieren und es auf den Kubernetes-Cluster anwenden, auf dem Crossplane installiert ist. Crossplane beginnt dann, den deklarierten Zustand mit der Datenbank beim Cloud-Provider zu synchronisieren. Um eine Datenbankressource in AWS bereitzustellen, müsste ein Entwickler Folgendes erstellen:

Crossplane liest die obige RDSInstance und erstellt in AWS eine Datenbank mit diesen Spezifikationen. Bei einer Änderung im Manifest gleicht Crossplane den Zustand ab und aktualisiert die Datenbank entsprechend. Werden über die AWS-Managementkonsole manuelle Änderungen an der Datenbankinstanz vorgenommen, setzt Crossplane diese automatisch zurück, sodass sie wieder dem in Kubernetes deklarierten Zustand entspricht.

Mit Crossplane für das Infrastrukturmanagement könnt ihr Ressourcen gleichzeitig bei mehreren Cloud-Providern bereitstellen, was vorteilhaft sein kann, da jeder Cloud-Provider ein anderes Angebot hat. Derzeit unterstützt Crossplane AWS, GCP und Microsoft Azure als Cloud-Provider. Ein DigitalOcean-Provider befindet sich ebenfalls in aktiver Entwicklung.

Warum Crossplane statt Terraform?

Für Infrastructure as Code (IaC) gibt es viele hervorragende Tools auf dem Markt, wobei Terraform das beliebteste ist. Crossplane und Terraform versuchen, dieselben Probleme zu lösen, indem sie euch ermöglichen, eure gesamte Infrastruktur als Code zu beschreiben. Crossplane bietet jedoch einige Vorteile gegenüber Terraform:

• Crossplane lässt sich einfach in GitOps-Workflows integrieren.

• Crossplane korrigiert Abweichungen automatisch.

• Crossplane benötigt keinen gespeicherten State.

Configuration Drift mit Terraform lässt sich durch ein automatisiertes Tool wie Atlantis oder ein Skript vermeiden, das regelmäßig einfach terraform apply ausführt, etwa der tf-controller für Flux.

Dadurch entsteht im Wesentlichen ein System, das wie eine Control Plane funktioniert. Statt ein Tool wie Terraform zu verwenden und es mit einem Automatisierungstool oder -skript zu ergänzen, kann es daher sinnvoller sein, ein auf einer Control Plane basierendes Tool zu nutzen, das genau für diesen Zweck entwickelt wurde.

Crossplane lässt Configuration Drift nur zu, wenn ihr die Reconciliation-Schleife absichtlich pausiert. Andernfalls synchronisiert Crossplane den Zustand kontinuierlich, solange es läuft. Nimmt jemand in der UI des Cloud-Providers manuelle Änderungen an einer Cloud-Ressource vor, setzt Crossplane diese auf den in Kubernetes deklarierten Zustand zurück. Änderungen an der Cloud-Ressource müssen daher über Crossplane erfolgen.

Wenn ihr eure Kubernetes-Ressourcen mit ArgoCD oder FluxCD verwaltet, könnt ihr eure Crossplane-Ressourcen zudem in Git einchecken und die gesamte Infrastrukturkonfiguration über ein Git-Repository verwalten. Das gewährleistet einen Audit Trail in Git und ermöglicht eurem Team, Infrastrukturänderungen über Pull Requests zu verwalten – oder über andere Git-Prozesse, die euer Team bereits nutzt.

Ein wesentlicher Nachteil von Terraform ist sein State, der verloren gehen oder beschädigt werden kann. Das kann zu Komplikationen führen, wenn ihr damit eure gesamte Infrastruktur verwaltet. Außerdem müsst ihr den State an einem Remote-Standort mit der richtigen Zugriffskontrolle speichern. Andernfalls hat nicht das gesamte Team Zugriff darauf. Das einzurichten, kann aufwendig und zeitintensiv sein.

Beim Anwenden von Änderungen berücksichtigt Terraform drei Elemente: eure lokalen Terraform-Dateien, den Terraform-State und den tatsächlichen Zustand beim Cloud-Provider. Weicht der Zustand beim Cloud-Provider vom gespeicherten Zustand ab, kann dies zu Komplikationen führen.

Crossplane hingegen betrachtet nur die deklarierten Ressourcen und die Ressourcen, die beim Cloud-Provider laufen. Es gibt keinen veränderlichen State, um den sich Crossplane kümmern muss.

Wie Terraform nutzt auch Crossplane das Konzept der Provider. Crossplane-Provider funktionieren ähnlich wie Terraform-Provider. Service Provider können ein Plugin erstellen, das sich in Crossplane integriert und Nutzern ermöglicht, externe Ressourcen auf ihrer Infrastruktur bereitzustellen. Der Service Provider ist dann dafür verantwortlich, den auf seiner Infrastruktur laufenden Zustand zu verwalten und sicherzustellen, dass er dem im Kubernetes-Cluster deklarierten gewünschten Zustand entspricht.

Warum Terraform statt Crossplane?

Wir haben die Vorteile von Crossplane hervorgehoben. Sehen wir uns nun an, was ihm im Vergleich fehlt.

Einer der größten Nachteile von Crossplane ist, dass ihr Änderungen nicht vor ihrer Anwendung in der Vorschau anzeigen könnt.

Mit Terraform kann der Entwickler terraform plan ausführen, um eine Vorschau der Änderungen zu sehen, bevor er die neue Konfiguration übernimmt. Crossplane bietet keine vergleichbare Funktion. Ihr könnt also keine Vorschau der Ressourcen anzeigen, die erstellt, geändert oder gelöscht werden. Entwickler können lediglich die Manifeste anwenden und hoffen, dass alles korrekt ist.

Angenommen, ihr benennt eure RDSInstance wie im obigen Beispiel um. Crossplane könnte die bestehende Datenbank löschen und eine neue mit dem neuen Namen erstellen. Das hängt von der Implementierung des Providers und den eingerichteten Schutzmechanismen ab, wodurch Crossplane für kritische Infrastruktur riskant sein kann. Dies wird auch in einem GitHub Issue beschrieben.

Crossplane-Änderungen vor dem Merge in die Produktion testen

Ihr könnt das Risiko verringern, eine falsche Konfiguration anzuwenden, indem ihr sie in einer Staging-Umgebung testet. Wichtig ist jedoch: Auch wenn die Staging-Umgebung der Produktionsumgebung möglichst ähnlich sein soll, wird sie nie identisch sein.

Es besteht immer das Risiko, dass die neue Konfiguration die Produktionsumgebung beeinträchtigt. Beim Einsatz von Crossplane für eure kritische Infrastruktur müsst ihr vorsichtig sein, denn es gibt keinen „Plan“-Schritt, in dem ihr eure Änderungen vor der Übernahme in die Produktion prüfen könnt.

Ihr könnt eure Änderungen zwar in Git zurücksetzen und zum vorherigen Zustand zurückkehren, eine gelöschte Produktionsdatenbank wird dadurch jedoch nicht wiederhergestellt oder neu erstellt. Stattdessen wird eine neue, unveränderte Datenbank erstellt – nicht gerade ein Fallback-Mechanismus.

Die Zukunft von Crossplane

Es ist ungewiss, ob Crossplane künftig eine Preview- oder „Dry-Run“-Funktion bieten wird, bei der die neue Konfiguration ausgeführt wird, ohne etwas zu verändern. Diese Funktion wird bereits seit über zwei Jahren diskutiert. Ich stelle mir vor, dass Preview-Funktionen für Control Planes grundsätzlich schwer umzusetzen sind, da nicht klar ist, an welcher Stelle im Prozess Entwickler die Änderungen prüfen würden.

Crossplane vs. Terraform

Crossplane bietet zwar mehrere Vorteile gegenüber Terraform und ähnlichen Tools, bleibt bei der Verwaltung kritischer Infrastruktur aufgrund der fehlenden Dry-Run-/Plan-Funktion jedoch hinter den Erwartungen zurück.

Mit dem Befehl terraform plan von Terraform können Entwickler Änderungen vor dem Commit einer neuen Konfiguration prüfen und validieren. Diese Funktion bietet eine zusätzliche Sicherheitsebene und hilft, unbeabsichtigte Änderungen zu verhindern.

Im Gegensatz dazu bietet Crossplane keine Preview-Funktion. Ohne die Möglichkeit, Änderungen im Voraus zu bewerten und zu prüfen, besteht ein höheres Risiko für Fehler und Störungen in der Produktionsumgebung.

Versteht mich nicht falsch: Ich halte Crossplane für ein großartiges Projekt und bin ein großer Fan. Wenn ich jedoch ein Unternehmen führen würde, wäre ich zurückhaltend, Crossplane für meine kritische Kerninfrastruktur einzusetzen.