Skip to content

Crossplane — Trivia & Interesting Facts

Surprising, historical, and little-known facts about Crossplane.


Crossplane was created by the company behind Rook

Crossplane was created by Upbound, the same company that created Rook (the Kubernetes storage orchestrator). CEO Bassam Tabbara and team saw that Kubernetes could manage compute and storage but couldn't manage cloud infrastructure itself. Crossplane was designed to fill that gap, turning Kubernetes into a universal control plane.


The core idea is "Kubernetes as a control plane for everything"

Crossplane's key insight is that Kubernetes already has a powerful reconciliation engine — it constantly compares desired state to actual state and makes corrections. Crossplane extends this engine to manage any external resource: cloud databases, DNS records, IAM policies, and anything else with an API.


Crossplane providers are generated from cloud API specs, not hand-written

Many Crossplane providers (the components that manage specific cloud resources) are generated from the cloud providers' API specifications rather than being hand-coded. This approach, called "code generation from schemas," allows Crossplane to support hundreds of resource types per provider without a human writing each one.


Compositions solve the "Terraform module" problem in Kubernetes

Crossplane Compositions allow platform teams to create higher-level abstractions (like "production database") that hide cloud-specific details from developers. This is analogous to Terraform modules but with a key difference: Compositions are reconciled continuously, not just applied once, so the actual state is constantly corrected to match the desired state.


Crossplane joined the CNCF in 2020 and graduated in 2024

Crossplane was accepted as a CNCF Sandbox project in June 2020 and became an Incubating project in September 2021. It achieved Graduated status in 2024, joining the elite group of projects (Kubernetes, Prometheus, Envoy, etc.) that the CNCF considers production-ready and widely adopted.


The "provider-terraform" lets you use Terraform inside Crossplane

In a meta twist, Crossplane has a provider that runs Terraform configurations as managed resources. This means you can use Crossplane to orchestrate Terraform modules, getting the reconciliation loop of Kubernetes with the resource coverage of Terraform. Some teams use this as a migration strategy from Terraform to native Crossplane providers.


Crossplane's biggest competitor might be Terraform — or AWS Controllers for Kubernetes

Crossplane competes in an unusual space: against Terraform (different paradigm entirely), AWS Controllers for Kubernetes (ACK), and Google's Config Connector (KCC). The difference is that Crossplane is cloud-agnostic and composable, while ACK and KCC are cloud-specific. Terraform, meanwhile, doesn't do continuous reconciliation.


Claims and XRDs were inspired by Kubernetes PVCs

Crossplane's Claim/CompositeResource model was directly inspired by how Kubernetes handles PersistentVolumeClaims and PersistentVolumes. A developer "claims" a resource (like a database) without knowing the implementation details, and the platform team's Composition determines how the claim is fulfilled — just like a StorageClass determines how a PVC becomes a PV.


Scaling Crossplane beyond 1,000 managed resources requires careful tuning

While Crossplane works well at moderate scale, managing more than 1,000 cloud resources from a single cluster requires careful tuning of controller concurrency, rate limits, and API server resources. The community has documented scaling patterns, but this operational complexity is Crossplane's most significant barrier to enterprise adoption.