Crossplane gegen Terraform: Control Plane statt State-Datei

Ein Entwickler braucht eine Datenbank für einen neuen Service. Er öffnet ein Ticket, das Platform-Team ergänzt ein Modul im Terraform-Repo, jemand reviewt den Plan, jemand wendet ihn an. Zwei Tage im besten Fall. Crossplane ändert den Weg: Der Entwickler wendet ein Manifest im eigenen Namespace an, danach übernimmt ein Controller. Der Unterschied liegt nicht im Tempo des Tickets, sondern im Modell. Terraform hält einen Snapshot des Zustands in einer Datei und gleicht ihn auf Zuruf ab, Crossplane macht die Kubernetes-API zur Control Plane und gleicht permanent ab.

Woraus eine Control Plane besteht

Ein Provider ist ein Plugin, das mit einer externen API spricht: AWS, GCP, Cloudflare, GitHub. Eine Managed Resource ist eine Low-Level-Ressource dieser API, gespiegelt als Kubernetes-Objekt. Dann beginnt die Plattformarbeit: Ein XRD deklariert das Schema eines eigenen abstrakten Typs, eine Composition beschreibt, wozu sich dieser Typ entfaltet. Der Entwickler sieht drei Felder statt zwanzig RDS-Feldern: size: medium, version: "16" und einen Namen. Alles Übrige ist der Vertrag des Platform-Teams, versteckt in der Composition.

Was Version zwei geändert hat

Crossplane hat die Inkubation verlassen: Die CNCF hat das Projekt im Oktober 2025 auf Graduated gesetzt, die aktuelle Linie ist v2.3 vom Mai 2026, Releases folgen einem Quartalszyklus. Version zwei hat das nutzerseitige Modell neu geschrieben, damit sind Artikel, in denen ein Entwickler einen Claim anlegt, an dieser Stelle veraltet.

• XRs sind standardmäßig namespaced (scope: Namespaced im XRD apiextensions.crossplane.io/v2), das separate Claim-Objekt ist entfallen — der Entwickler legt das XR direkt im eigenen Namespace an.
• Managed Resources sind ebenfalls namespaced, Provider haben API-Gruppen mit .m. bekommen, etwa s3.aws.m.upbound.io/v1beta1.
• Eine Composition setzt beliebige Kubernetes-Ressourcen zusammen, provider-kubernetes als Umweg für Objekte im Cluster entfällt damit.
• Natives Patch & Transform (mode: Resources) wurde entfernt, geblieben ist nur mode: Pipeline mit Composition Functions in Go, Python oder KCL. Reines YAML gibt es weiter als function-patch-and-transform, für die Migration existiert crossplane beta convert pipeline-composition.
• Operations decken Day 2 ab: wiederkehrende Jobs wie Cleanup und Audits werden als Ressource beschrieben statt als CronJob daneben.

Was kontinuierlicher Abgleich bringt

Drift. Terraform erfährt von einer Änderung, die jemand von Hand in der Konsole gemacht hat, erst wenn ein Plan läuft — beim nächsten Release oder im wöchentlichen Job. Der Crossplane-Controller vergleicht Soll und Ist permanent und zieht die Ressource ohne Zutun eines Menschen auf das Manifest zurück. Dieselbe Eigenschaft liefert Day-2-Betrieb gratis: Reconciliation, Status und Events laufen über den Mechanismus, den man von Deployments kennt.

Self-Service. Zugriffssteuerung ist gewöhnliches Namespace-RBAC, die Änderungshistorie ist das Audit-Log des Clusters, die Auslieferung übernimmt ArgoCD, das ein XR wie jedes andere Manifest synct. Terraform bekommt für Self-Service einen Aufsatz wie Atlantis oder Spacelift, und den betreibt ebenfalls jemand.

Was es kostet

„Keine State-Datei, also besser“ steht in jedem Vergleich und bleibt das unehrlichste Argument. Die Datei ist weg, der Zustand nicht: Er liegt im etcd des eigenen Clusters. Daraus folgen drei Dinge.

Beobachtbarkeit. Auf die Frage „was ist deployed und in welchem Zustand“ antwortet Terraform mit einem Kommando, Crossplane mit einer Reihe von kubectl-Aufrufen und Werkzeugen wie k9s oder der crossplane CLI. Belege im großen Maßstab: Der stateful Workflow mit Plan-Review ist auf Installationen mit Tausenden Ressourcen erprobt, öffentliche Berichte dieser Größe sind bei Crossplane deutlich seltener. Wiederherstellung: Der Control-Plane-Cluster wird zum Produktionssystem, etcd-Backup, Restore-Prozedur und Zugänge liegen damit bei Ihnen statt in einer Zeile über ein S3-Backend.

Ein eigener Posten ist die Lernkurve. XRD, Composition und Functions bedeuten Entwicklung einer Plattform-API, nicht „HCL geschrieben“. Es braucht ein Team, das den Vertrag besitzt, das Schema versioniert und Fragen dazu beantwortet. Ohne dieses Team wird Crossplane zum selben Terraform, nur schwerer zu debuggen.

Wo ich die Grenze ziehe

OpenTofu oder Terraform für Day 0: Netz, Cluster, IAM-Fundament, einschließlich des Clusters für die Control Plane. Crossplane ab Day 1: Datenbanken, Queues, Buckets und Repositories, die Teams jede Woche für ihre Services bestellen. Die untere Schicht ändert sich selten und verlangt Plan-Review, die obere ändert sich oft und verlangt Self-Service. Die Wahl zwischen OpenTofu und Terraform verschiebt diese Grenze nicht, dazu gibt es eine eigene Analyse.

Drei Fehler, die sofort auffallen

• Ein XR ohne RBAC und Namespace-Isolation: Ein Entwickler bekommt die Möglichkeit, die Produktion des Nachbarteams zu kippen.
• Eine Composition ohne writeConnectionSecretsToNamespace: Das Datenbankpasswort landet nicht dort, wo die Anwendung es erwartet.
• Eine Composition mit zwei Dutzend Ressourcen in reinem YAML: eine Wand aus Patches, die niemand liest, statt einer Function mit Tests.

Crossplane gewinnt nicht durch die fehlende State-Datei, sondern dadurch, dass Infrastruktur zur API mit versioniertem Schema und permanentem Abgleich wird. Der Preis ist ein Platform-Team, das diese API entwirft und pflegt. Fehlt es, ist Terraform die ehrlichere Wahl.