Crossplane 2026: Kubernetes-natives Infrastructure-as-Code als Plattform-Engine

Wenn Plattform-Teams heute über Internal Developer Platforms (IDPs) sprechen, fallen oft die Namen Backstage, Argo CD und Kubernetes. Ein Projekt bleibt dabei häufig im Hintergrund, obwohl es die entscheidende Schicht darunter bildet: Crossplane. Das CNCF-graduierte Framework macht Cloud-Infrastruktur zu Kubernetes-Ressourcen – und hat sich 2026 mit einer Reihe von Releases und dem neuen Modelplane-Projekt endgültig als zentrale Plattform-Engine etabliert.

Vom Control Plane Framework zur Plattform-Engine

Crossplane wurde 2018 von Upbound open-sourced und trat 2020 der CNCF bei. Was als spezialisiertes Werkzeug für „Control Planes" begann, ist heute ein graduiertes CNCF-Projekt – im gleichen Governance-Rang wie Kubernetes, Prometheus und Helm. Über 3.000 Mitwirkende aus mehr als 450 Organisationen haben inzwischen über 100 Releases beigesteuert, die kumulierten Downloads übersteigen 100 Millionen. Zu den produktiven Nutzern zählen Nike, SAP, IBM, Elastic, Autodesk und die NASA Science Cloud.

Der entscheidende Paradigmenwechsel: Crossplane bildet Cloud-Ressourcen nicht als externe State-Dateien ab (wie Terraform oder OpenTofu), sondern als native Kubernetes-Objekte. Ein S3-Bucket, eine PostgreSQL-Datenbank oder ein IAM-Rolle werden zu YAML-Manifesten, die kubectl apply erwartet und die Argo CD oder Flux per GitOps synchronisieren. Der Kubernetes-etcd übernimmt State-Management und Locking – keine separate State-Backend-Konfiguration, kein manuelles terraform plan.

Crossplane v2: Der Architektursprung

Im August 2025 erschien Crossplane v2.0 – der größte architektonische Einschnitt seit Bestehen des Projekts. Drei Änderungen waren besonders folgenreich:

Namespaced Resources: Managed Resources leben standardmäßig in Namespaces und erben damit Kubernetes-RBAC. Multi-Tenancy wird zu einer inhärenten Eigenschaft, nicht zu einer nachträglich konfigurierten Option.

Composition Functions: Statt statischer Patch-&-Transform-Vorlagen können Plattform-Teams seit v2.0 Composition Functions in Go, Python oder CEL schreiben. Diese Funktionen berechnen den gewünschten Infrastrukturzustand zur Laufzeit – mit Schleifen, Bedingungen und Logik, die reine YAML-Vorlagen nie abbilden konnten.

Jede Kubernetes-Ressource ist komponierbar: Eine einzelne Composition kann nicht nur Cloud-Ressourcen wie RDS-Instanzen erzeugen, sondern gleichzeitig Deployments, Services, ConfigMaps und Monitoring-Regeln im selben Cluster anlegen. Was früher mehrere Tools und Pipelines erforderte, wird zu einem einzigen deklarativen Objekt.

Seitdem hat Crossplane im Dreimonats-Rhythmus weiter zugelegt: v2.2 (März 2026) brachte den Pipeline Inspector – ein dringend benötigtes Debugging-Tool für Composition Functions – sowie CEL-Validierung direkt in den Composite Resource Definitions. v2.4 (September 2026) ist die aktuelle stabile Version; v2.5 ist für November 2026 angekündigt.

Modelplane: GPU-Inferenz als Composite Resource

Der vielleicht spannendste Meilenstein 2026 ist Modelplane, angekündigt von Crossplane-Mitbegründer Nic Cope im Juni. Modelplane ist eine Open-Source-Steuerungsebene für verteilte GPU-Inferenz – und bemerkenswerterweise „von oben bis unten eine Crossplane-Konfiguration", wie Cope es formulierte. Es enthält keine einzigen benutzerdefinierten Controller, sondern besteht ausschließlich aus Compositions und Composition Functions.

Das Ressourcenmodell bildet GPU-Cluster als InferenceCluster und Modell-Deployments als ModelDeployment ab. Eine flottenweite Composition Function (in Python) entscheidet über die optimale Platzierung, während der normale Kubernetes-Scheduler die Pods dann an bestimmte GPUs bindet. Modelplane zeigt eindrucksvoll, wie weit das Crossplane-Designprinzip trägt: Selbst KI-Workloads werden zu einer deklarativen Kubernetes-API.

Crossplane im Plattform-Stack

Crossplane ist kein Terraform-Ersatz für jede Gelegenheit. Wer bereits Kubernetes in der Produktion betreibt und ein Internal Developer Platform aufbaut, profitiert von der kontinuierlichen Drift-Erkennung, der natives GitOps-Integration und der fein granulareren RBAC. Für einmalige Infrastrukturbereitstellung ohne Kubernetes-Basis – oder tief in HCL verwurzelte Teams – bleiben Terraform und OpenTofu die richtige Wahl.

Die eigentliche Stärke von Crossplane zeigt sich im Zusammenspiel: Backstage als Developer Portal, Argo CD als GitOps-Engine und Crossplane als Infrastruktur-Control-Plane ergeben einen vollständigen Plattform-Stack, der Entwicklern Self-Service-Zugriff auf Cloud-Ressourcen gibt, ohne dass sie Cloud-Konsolen oder HCL-Syntax beherrschen müssen.

Fazit

Crossplane hat sich 2026 von einem Nischenprojekt für Kubernetes-Enthusiasten zu einer ernstzunehmenden Plattform-Engine entwickelt. Die CNCF-Graduierung, der Architektursprung auf v2 und nicht zuletzt Modelplane als Proof-of-Concept für KI-gesteuerte Infrastruktur belegen: Das deklarative Control-Plane-Modell ist keine Spielerei mehr, sondern produktionsreif. Plattform-Teams, die 2026 ihren Stack aufbauen, sollten Crossplane nicht als „Terraform-Alternative" betrachten, sondern als das, was es ist: eine eigene Kategorie von Infrastruktur-Werkzeugen.