What is Crossplane and how does it enable infrastructure as code using Kubernetes?

Imagine you have a central command center that already runs your applications. Instead of having a separate room with different controls for your cloud infrastructure, what if you could manage everything from that same command center using the same language and processes? That is exactly what Crossplane does. It turns your existing Kubernetes cluster into a unified control plane that can provision and manage infrastructure across AWS, GCP, Azure, and any other cloud provider, all through the familiar Kubernetes API.

Crossplane installs as a set of controllers inside your Kubernetes cluster. Once installed, it extends the Kubernetes API by registering Custom Resource Definitions (CRDs) for cloud resources like RDS databases, S3 buckets, VPCs, and Cloud SQL instances. When you apply a YAML manifest describing an AWS RDS instance, the Crossplane controller picks it up from the API server, calls the AWS API to create the actual database, and then continuously reconciles the desired state in your YAML with the real state in AWS. If someone manually changes the database configuration through the AWS console, Crossplane detects the drift and corrects it automatically, just like how a Kubernetes Deployment controller replaces a crashed Pod.

For a team running the payments-api service, this means the same GitOps pipeline that deploys application code can also provision the PostgreSQL database that payments-api depends on. The infrastructure YAML lives in the same repository, goes through the same pull request review, and gets applied by the same ArgoCD or Flux pipeline. A developer on the order-processing-service team does not need AWS console access or Terraform CLI installed locally. They simply write a Kubernetes manifest, push it to Git, and the infrastructure appears. This eliminates the traditional handoff between development and infrastructure teams, where a developer submits a Jira ticket and waits days for a database to be provisioned.

The reconciliation loop is what makes Crossplane fundamentally different from imperative infrastructure tools. Terraform runs once and produces a state file, but between runs, your infrastructure can drift without detection. Crossplane controllers run continuously inside the cluster, watching for changes every few seconds. If the inventory-sync service needs a Redis cache and someone accidentally deletes it from the cloud console, Crossplane recreates it automatically. This continuous reconciliation model means your infrastructure is self-healing, just like your application workloads already are under Kubernetes.

Crossplane also introduces a powerful abstraction layer through Compositions and Composite Resources, which let platform teams define opinionated infrastructure templates. Instead of exposing raw cloud primitives to every developer, the platform team can create a custom DatabaseClaim resource that bundles an RDS instance, a security group, a subnet group, and a Kubernetes Secret with connection details. The checkout-service team just creates a DatabaseClaim and gets a fully configured, production-ready database without knowing the underlying cloud specifics. This separation of concerns between platform engineers and application developers is one of the core design principles of Crossplane.