Crossplane – Kubernetes-native Control Plane für moderne Plattform-Teams

Crossplane hat sich in kurzer Zeit von einem Nischenprojekt zu einem zentralen Baustein moderner Plattform-Engineering-Ansätze entwickelt. Als Kubernetes-native Control-Plane-Erweiterung erlaubt es, Infrastruktur, Plattformdienste und sogar SaaS-Ressourcen über deklarative APIs zu steuern. Seit seiner Graduation als CNCF-Projekt im Herbst 2025 gilt Crossplane als ausgereifte, produktionsreife Technologie für Enterprise- und Behördenumgebungen.

Begriffserklärung & Einleitung

Crossplane ist ein Open-Source-Framework, das Kubernetes zur universellen Control Plane für Infrastruktur und Anwendungen erweitert. Technisch handelt es sich um ein Kubernetes-Addon: Crossplane installiert Custom Resource Definitions (CRDs) und Controller, die neue Kubernetes-APIs bereitstellen, mit denen externe Ressourcen – etwa Cloud-Services, Datenbanken, Message-Broker oder SaaS-Dienste – verwaltet werden können.

Im Unterschied zu klassischen Infrastructure-as-Code-Werkzeugen wie Terraform ist Crossplane selbst eine kontinuierlich laufende Control Plane. Es übernimmt das aus Kubernetes bekannte Muster der „Desired State“-Verwaltung: Der gewünschte Zustand wird deklarativ beschrieben, und Crossplane sorgt dafür, dass die Realität dauerhaft diesem Zielzustand entspricht – inklusive Drift-Erkennung und -Korrektur.

Im aktuellen IT-Umfeld gewinnt Crossplane insbesondere in folgenden Kontexten an Bedeutung:

Plattform-Engineering & Internal Developer Platforms (IDP)
Multi-Cloud- und Hybrid-Strategien
Compliance- und Governance-Anforderungen in regulierten Branchen
GitOps-basierte Bereitstellungsprozesse

Mit der CNCF-Graduation 2025 wird deutlich: Crossplane ist kein Experiment mehr, sondern ein strategischer Baustein für Cloud-native Plattformen.

Funktionsweise & technische Hintergründe

Kubernetes als Control Plane mit Crossplane

Kernidee von Crossplane ist, die Kubernetes-API als gemeinsame Sprache für Infrastruktur zu nutzen. Statt für jede Cloud oder jedes Tool eigene APIs und CLIs zu bedienen, werden alle Ressourcen als Kubernetes-Objekte modelliert.

Die wesentlichen Bausteine:

Managed Resources
Repräsentieren einzelne externe Ressourcen (z. B. RDSInstance, Bucket, VPC). Diese Ressourcen werden von Providern bereitgestellt.
Provider
Provider sind Crossplane-Pakete, die CRDs und Controller für eine bestimmte Plattform mitbringen (AWS, Azure, GCP, Kubernetes, Datenbanken, GitHub, Terraform, Helm u. v. m.). Sie kapseln Authentifizierung, API-Aufrufe und die Lebenszykluslogik der entsprechenden Ressourcen.
Composite Resources (XR/XRD)
Composite-Ressourcen fassen mehrere Managed Resources zu einer höheren Abstraktion zusammen, etwa „Produktionsdatenbank“ oder „Standard-Microservice-Umgebung“. Die API dieser Composite-Ressourcen wird über CompositeResourceDefinitions (XRDs) definiert.
Compositions & Composition Functions
Eine Composition beschreibt, wie aus einer Composite-Ressource konkrete Managed Resources gebildet werden. Neuere Crossplane-Versionen setzen auf Composition Functions (Pipeline-Modell), um komplexe Transformations- und Validierungslogik umzusetzen – u. a. auch mit Sprachen wie KCL statt reinem YAML.
Crossplane Packages
Provider und Konfigurationen werden als OCI-Images („Crossplane Packages“) ausgeliefert und können aus Container-Registern installiert und versioniert werden.

Declarative Reconciliation & Drift-Handling

Crossplane läuft dauerhaft im Kubernetes-Cluster und beobachtet seine CRDs. Für jede deklarierte Ressource:

Liest Crossplane den Desired State aus der Kubernetes-API.
Vergleicht diesen mit dem Ist-Zustand im Zielsystem (Cloud, SaaS, etc.).
Erzeugt oder aktualisiert Ressourcen über die Provider-Controller.
Korrigiert Abweichungen laufend (Drift-Reconciliation).

Damit unterscheidet sich Crossplane fundamental von Tools wie Terraform, die meist per CLI „on demand“ ausgeführt werden und Drift nur über zusätzliche Schritte erkennen.

Namespaced vs. Cluster-Scoped Ressourcen (Crossplane v2)

Mit Crossplane v2 wurde die Architektur weiter verfeinert:

Unterstützung für namespaced Composite Resources, wodurch klarere Mandantentrennung und Delegation möglich werden.
Möglichkeit, beliebige Kubernetes-Ressourcen zu komponieren, nicht nur Managed Resources.
Vereinheitlichung und Modernisierung der Compositions (Pipeline-Modell, Functions) gegenüber älteren Patch-&-Transform-Mechanismen.

Dazu kommen im CLI u. a. Befehle wie crossplane render und crossplane validate, um Compositions lokal zu testen und zu validieren, bevor sie auf ein Cluster angewendet werden.

Kurzes YAML-Beispiel

Ein stark vereinfachtes Beispiel für eine Composite-Ressource „Postgres-Datenbank“:

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xpostgresinstances.platform.example.org
spec:
  group: platform.example.org
  names:
    kind: XPostgresInstance
    plural: xpostgresinstances
  claimNames:
    kind: PostgresInstance
    plural: postgresinstances
  versions:
    - name: v1alpha1
      served: true
      referenceable: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                parameters:
                  type: object
                  properties:
                    size:
                      type: string

Eine passende Composition würde dann z. B. eine Subnetz-Konfiguration, ein Security Group und eine konkrete Datenbankinstanz in AWS erstellen.

Anwendungsbeispiele in der Praxis

Plattform-Engineering & Internal Developer Platforms

Plattform-Teams können mit Crossplane eigene domänenspezifische APIs definieren, etwa:

CompositeApplication
BusinessService
ProductionDatabase

Entwicklungsteams konsumieren diese APIs wie „normale“ Kubernetes-Ressourcen (per kubectl oder GitOps), ohne die Komplexität der zugrunde liegenden Cloud- oder Netzwerk-Topologie zu kennen. Crossplane setzt im Hintergrund Netzwerk, Datenbanken, Message-Broker, Observability-Stacks etc. auf.

Das Ergebnis: Self-Service-Umgebungen mit klaren Guardrails und konsistenten Standards.

Multi-Cloud- und Hybrid-Szenarien

Über Provider für AWS, Azure, GCP, Datenbanken, Kubernetes, GitHub und andere Plattformen kann Crossplane Infrastruktur über mehrere Clouds und On-Prem-Systeme hinweg einheitlich verwalten.

Beispiele:

Standardisierte Netzwerk- und Sicherheitszonen in allen Hyperscalern
Einheitliche Datenbank-Blueprints für mehrere Clouds
Integration von SaaS-Diensten (z. B. Monitoring, CI/CD, Repos) in ein konsistentes Plattformmodell

GitOps & Policy-as-Code

Kombiniert mit GitOps-Tools wie Argo CD oder Flux werden Crossplane-Konfigurationen versioniert in Git verwaltet. Änderungen an Compositions oder XRDs durchlaufen denselben Review- und Rollout-Prozess wie Applikationsmanifeste.

Über Policy-Engines wie OPA oder Kyverno lassen sich zusätzliche Compliance-Regeln auf CRDs und Namespaces anwenden, etwa:

Welche Teams dürfen welche XRDs nutzen?
Welche Cloud-Regionen oder -Instanzgrößen sind erlaubt?

Gerade für regulierte Branchen und Behörden bietet das eine robuste Grundlage für Auditierbarkeit und Governance.

Vorteile und Herausforderungen

Zentrale Vorteile von Crossplane

Einheitliche API
Alles, was Crossplane verwaltet, wird über die Kubernetes-API angesprochen. Kubernetes-Know-how bleibt also nutzbar und skalierbar.
Kontinuierliche Reconciliation
Crossplane läuft permanent und korrigiert Drift automatisch – ein deutlich anderer Betriebsmodus als batch-orientierte IaC-Tools.
Starke Abstraktion via Compositions
Fachliche APIs (z. B. „Produktions-Workspace“) kapseln technische Details. Teams arbeiten mit stabilen, domänenspezifischen Interfaces.
Reifes Ökosystem & CNCF-Graduation
Mit v2.x, mehr als 100 Releases und einem breiten Provider-Ökosystem gehört Crossplane inzwischen zu den gereiften CNCF-Projekten.
Nahtlose Integration in Cloud-Native-Stacks
Crossplane integriert sich gut mit Argo, Flux, Helm, Backstage, Observability-Stacks oder Secret-Management-Lösungen und fügt sich damit in bestehende Plattformlandschaften ein.

Herausforderungen und Risiken

Kubernetes als Voraussetzung
Crossplane setzt mindestens einen Kubernetes-Cluster voraus. Für Organisationen ohne Kubernetes-Strategie oder mit stark heterogenen Umgebungen kann das ein Hemmnis sein.
Komplexität und Lernkurve
Konzepte wie XRDs, Compositions, Functions und Provider-Konfiguration erfordern erfahrene Plattform- und SRE-Teams. Für kleinere Teams kann Terraform o. Ä. einfacher sein.
Zusätzliche Betriebs- und Sicherheitsanforderungen
Crossplane muss hochverfügbar, sicher und passgenau in RBAC-, Netzwerk- und Secret-Konzepte eingebettet werden. Fehler in Compositions wirken sich unter Umständen auf viele Mandanten aus.
Provider-Reife und -Abdeckung
Während Provider für große Hyperscaler und gängige Dienste gut ausgereift sind, können Nischen-Services oder Spezial-APIs Lücken aufweisen oder zusätzliche Integrationsarbeit erfordern.
Performance & Kosten
Crossplane bringt Overhead in das Kubernetes-Cluster ein. In vielen Szenarien ist dies akzeptabel, aber bei sehr großen Infrastrukturen ist eine saubere Kapazitätsplanung notwendig.

Alternative Lösungen

Crossplane konkurriert nicht nur mit klassischen IaC-Tools, sondern ergänzt diese oft:

Terraform
Deklaratives IaC mit HCL, enorme Community, viele Provider. Stärker als „Statemachine mit Plan/Apply-CLI“, weniger als dauerhafte Control Plane.
Pulumi
Infrastructure-as-Code in Programmiersprachen (TypeScript, Go, Python …). Geeignet, wenn Teams imperative Logik und bestehende Dev-Toolchains nutzen wollen.
Cloud-native Tools (Bicep, AWS CDK, CloudFormation)
Empfehlenswert bei starker Bindung an einen Cloud-Anbieter, weniger bei Multi-Cloud-Ansätzen.
Kubernetes Operators & Cluster API
Für bestimmte Ressourcen (z. B. Kubernetes-Cluster) existieren spezialisierte Operatoren; Crossplane kann diese ergänzen, aber nicht immer vollständig ersetzen.

In der Praxis werden Crossplane und Terraform/Pulumi häufig kombiniert, etwa indem Terraform über sein Kubernetes-Provider-Plugin Crossplane-Ressourcen definiert, während Crossplane als laufende Control Plane fungiert.

Fazit mit kritischer Bewertung

Crossplane hat sich zu einem mächtigen Framework für Kubernetes-basierte Control Planes entwickelt und ist durch die CNCF-Graduation auch formal als reife, produktionsreife Technologie bestätigt.

Für Architekt:innen und Plattform-Teams ist Crossplane besonders attraktiv, wenn:

Kubernetes ohnehin das zentrale Ausführungs- und Orchestrierungs-Backend ist,
eine einheitliche, domänenspezifische API für Infrastruktur geschaffen werden soll,
Self-Service, Governance und GitOps miteinander verbunden werden sollen.

Administrator:innen und SREs profitieren von der konsistenten Reconciliation-Logik, der Integration in bestehende Observability-Stacks und der Möglichkeit, Infrastrukturänderungen wie Applikationsdeployments zu behandeln.

Entscheider:innen sollten Crossplane vor allem dann in Betracht ziehen, wenn eine langfristige Plattform-Strategie mit klaren APIs, Multi-Cloud-Fähigkeit und hoher Automatisierung verfolgt wird. Für kleinere Umgebungen oder Projekte ohne Kubernetes-Fokus kann ein reines IaC-Tool (Terraform, Pulumi, Bicep etc.) pragmatischer sein.

Kurz gesagt:
Wer bereits stark auf Kubernetes setzt und eine moderne Plattform-Engineering-Strategie aufbauen möchte, für den ist Crossplane mehr als nur ein weiteres Tool – es ist ein potenzieller Kernbaustein der eigenen Cloud-Plattform.

Autor

Michael Deinhard

Artikel erstellt: 03.12.2025
Artikel aktualisiert: 04.12.2025

zurück zur Übersicht