Crossplane

Wed, 03 Jun 2026 00:00:00 +0000

Crossplane is Kubernetes-native infrastructure management. Where Terraform runs as a CLI tool that applies changes and exits, Crossplane runs as a controller inside a Kubernetes cluster and continuously reconciles infrastructure — the same control loop model as Kubernetes itself.

Cloud resources become Kubernetes objects. You kubectl apply an RDS instance the same way you apply a Deployment. Crossplane’s controllers watch those objects and make the API calls to converge actual infrastructure to the desired state.

Core concepts

Providers extend Crossplane with CRDs for a specific cloud. provider-aws adds Kubernetes resources for every AWS service — S3 buckets, RDS instances, VPCs. Apply a provider, get hundreds of new resource types.

Managed Resources (MRs) are the individual cloud resources:

apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
 name: my-assets
spec:
 forProvider:
 region: eu-central-1
 tags:
 Environment: prod

Crossplane creates this bucket and keeps it in sync. If someone deletes it outside of Crossplane, the controller recreates it.

Composite Resources (XRs) are the powerful part. You define your own CRDs — a Platform or DatabaseCluster — that compose multiple managed resources. A developer applies a DatabaseCluster and gets an RDS instance, a subnet group, a parameter group, and security groups, all wired together, without needing to know any of the details.

XRDs (Composite Resource Definitions) define the schema for composite resources — what fields the developer sees, what defaults apply.

Compositions define how a composite resource maps to managed resources — the implementation behind the abstraction.

The platform engineering model

Crossplane’s real value is as a platform layer. A platform team owns the Compositions — they define what a “compliant database” or “standard app environment” looks like. Dev teams consume the simplified abstractions without touching the underlying cloud resources.

Self-service infrastructure with guardrails baked in.

vs Terraform

Crossplane and Terraform are not direct alternatives — they solve the problem differently.

Terraform is a CLI tool: run plan, review, apply, exit. State is a file. Good for human-in-the-loop workflows and one-off provisioning.

Crossplane is a control plane: always running, always reconciling. Better for continuous enforcement and self-service platforms. More complex to set up and operate.

In practice: Terraform for provisioning foundational infrastructure (clusters, networks, accounts). Crossplane for what runs on top of the cluster — letting application teams provision their own databases, queues, and object storage through Kubernetes-native APIs.

Upbound

The commercial platform behind Crossplane. Managed control plane hosting, a marketplace of providers and compositions, and tooling for building and publishing your own platform APIs. Worth evaluating if you are building a serious internal platform.

Learning curve

Steep. You need to understand Kubernetes controllers, CRDs, and the Crossplane composition model before you can be productive. The payoff is a genuinely powerful platform abstraction — but it is not a beginner tool.

A good framing: Crossplane is a digital twin of your infrastructure. The cluster holds the desired state of everything — cloud resources, application configuration, other tools — and continuously reconciles reality to match it.

Genuinely cool and worth learning if you have a cluster. The provider model has expanded well beyond cloud infrastructure — from v2 onwards Crossplane can manage applications, not just infra. There are also providers for Ansible and Terraform/OpenTofu, which means Crossplane can be the orchestration layer that drives other IaC tools. One control plane to rule them all.

The prerequisite is the cluster itself. If you already run Kubernetes, Crossplane is a natural extension of the same model you already operate. If you do not, it is not the tool to start with.

Rook

Thu, 14 May 2026 00:00:00 +0000

Rook is a Kubernetes operator that deploys and manages storage systems — primarily Ceph — as native Kubernetes resources. The distinction: Ceph is the storage system; Rook is the Kubernetes wiring around it.

Without Rook you would run Ceph manually (or via cephadm) and then configure the Kubernetes CSI driver separately. Rook collapses that into CRDs and handles the full lifecycle: deployment, configuration, expansion, upgrades, and failure recovery.

How it works

Rook introduces several CRDs:

CephCluster — declares the cluster: which nodes, which disks to use as OSDs, replication settings.

CephBlockPool — defines a Ceph pool (replication factor, failure domain). Maps to an RBD pool.

StorageClass — references a CephBlockPool and enables dynamic PVC provisioning. Kubernetes workloads request storage; Rook/Ceph fulfils it.

CephFilesystem — deploys CephFS + MDS for POSIX shared filesystem access.

CephObjectStore — deploys the Ceph RGW S3-compatible object storage gateway.

Typical install sequence

kubectl apply -f https://raw.githubusercontent.com/rook/rook/refs/tags/v1.17.9/deploy/examples/crds.yaml
kubectl apply -f https://raw.githubusercontent.com/rook/rook/refs/tags/v1.17.9/deploy/examples/common.yaml
kubectl apply -f https://raw.githubusercontent.com/rook/rook/refs/tags/v1.17.9/deploy/examples/operator.yaml

Then apply a CephCluster manifest declaring your storage topology, followed by CephBlockPool and StorageClass for PVC support.

Single-node considerations

A single-node setup requires allowMultiplePerNode: true in the CephCluster spec (MONs, MGR, and OSDs all land on the same node). Replication size must be set to 1 — there is nowhere else to replicate. This works for experimentation; it is not a production configuration. See Ceph for details on the replication model.

Rook documentation
Ceph — the underlying storage system
Rook + Ceph in the homelab

Operator on Backend Engineering Strategy Tools