TL;DR: Crossplane is a Kubernetes-native control plane framework that lets platform teams define abstractions for infrastructure and expose self-service APIs to developers.
Imagine working in a multi-cloud environment alongside infrastructure and development teams.
You need to provision, secure, and standardize cloud infrastructure across vendors while giving developers self-service access. You could manage this manually through fragmented tools, but it becomes much simpler when a single control plane manages infrastructure through standard Kubernetes APIs. Crossplane provides this control-plane framework.
What is Crossplane ?
By definition on their own website:
Crossplane is a control plane framework for platform engineering.
Crossplane lets you build control planes to manage your cloud native software. It lets you design the APIs and abstractions that your users use to interact with your control planes.
How Crossplane Differs from Tools Like Terraform
While both are declarative infrastructure tools, their execution models and control loops differ fundamentally. Terraform operates as a pipeline-driven CLI engine, whereas Crossplane functions as a continuous, Kubernetes-native control plane.
Core Architectural Differences
| Feature | Terraform / OpenTofu | Crossplane |
|---|---|---|
| Model | Declarative IaC | Kubernetes-native control plane |
| Execution | CLI or CI/CD-driven plan / apply workflow | Continuous reconciliation inside Kubernetes |
| Language | HCL, JSON, or CDKTF (Python, TypeScript, Go, Java) | Kubernetes YAML, KCL, or gRPC Composition Functions (Go, Python, etc.) |
| State Storage | State file managed by Terraform/OpenTofu | Kubernetes API resources and status, normally persisted through Kubernetes etcd |
| Drift Detection | Passive (only detects drift when running terraform plan) | Continuously reconciled by Crossplane controllers |
| Policy Engine | Often integrated with CI/CD policy and validation tools | Can integrate with Kubernetes admission and policy mechanisms |
| Abstraction | Terraform Modules | Composite Resource Definitions (XRDs) and Compositions |
In Crossplane, MR (Managed Resource) and XR (Composite Resource) represent the two core levels of infrastructure abstraction inside the Kubernetes Control Plane.
A Managed Resource (MR) is a Kubernetes Custom Resource that represents an individual external infrastructure resource managed by Crossplane. Examples include an AWS S3 bucket, a GCP Cloud SQL instance, or an Azure Virtual Network.
Managed Resources are reconciled by Crossplane provider controllers, such as the AWS, GCP, or Azure providers. The resource specification contains the configuration exposed by the provider for that particular cloud resource.
The purpose of the Managed Resource layer is to represent individual infrastructure resources as Kubernetes resources while allowing Crossplane to continuously reconcile them with the corresponding external resource.
Example MR Manifest:
apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
name: my-app-raw-bucket
spec:
forProvider:
region: us-east-1
A Composite Resource (XR) is a higher-level Kubernetes resource defined by platform engineers. It represents an application or platform concept rather than a single cloud-provider resource.
Crossplane Compositions define how the XR is translated into the underlying Managed Resources. Compositions can be defined using different approaches, including YAML-based resources and Composition Functions.
The objective is to encapsulate platform standards such as naming conventions, networking, security, and compliance requirements. Developers can then request a higher-level service by supplying only the parameters exposed by the platform API.
Example XR Manifest:
apiVersion: platform.example.com/v1alpha1
kind: PostgresInstance
metadata:
name: production-db
spec:
parameters:
storageGB: 50
environment: production
Concept
Kubernetes API > Crossplane > MR > XR > Composition > Provider > Cloud API
Back to Certified Cloud Native Platform Engineering Associate Preparation