Crossplane turns Kubernetes into a general-purpose control plane: ops author golden APIs as CRDs, and developers get cloud resources from plain YAML instead of ticket queues or Terraform DSLs.
The scenario in the note: days of ticket ping-pong for one test database versus a golden Postgres API that provisions encrypted RDS, private subnets, secrets, and backups behind the scenes.
Four major components: Composition, Managed Resources, Operations, and Packages, built on CRDs like XRD and Provider.
The developer gets what; ops controls how.
Why Crossplane (Scenario)
Before Crossplane:
Every time a developer needed a database, the story was the same.
Developer: I want a PostgreSQL database to test a new implementation.
Ops team: Which region? Which VPC? Public or private subnets? IAM roles? Encryption? Back up policy?
Developer: I just want a database…
Days pass. Emails bounce back and forth. Tickets pile up. Approvals are required.
One team enables backups. Another forgets encryption. Someone deploys in the wrong region.
Infrastructure becomes slow, inconsistent, and fragile.
After Crossplane:
The Ops team builds a golden platform API once.
kind: Postgres spec: size: small region: ap-south-1
That’s it.
Developers use it whenever they need a database no tickets, no emails.
Behind the scenes, Crossplane quietly takes care of everything:
Encrypted RDS
Private subnets
Security groups
Secrets management
Automated backups
The developer gets what they want. Ops controls how it’s done.
Crossplane Is the Cloud-Native Framework for Platform Engineering. Create platforms like cloud providers. Build your own APIs and services with control planes. Extend Kubernetes to manage any resource anywhere. Use a library of components to assemble your platform faster
Crossplane creates additional Control Plane(s) inside Kubernetes which act as the orchestration layer for resources in your cloud systems.
It offers this functionality by allowing you to create your own custom resources, templating, and workflows which are offered to consumers as Kubernetes CRDs.
This allows consumers to create and manage cloud resources via the same YAML manifests used elsewhere in Kubernetes and removes the burden for development teams to learn domain specific languages (as are needed for Terraform, CloudFormation, ARM Templates etc.)
After Kubernetes v1.7, Kubernetes was no longer just a container orchestrator. With Custom Resource Definitions (CRDs), it became a general-purpose control plane that can manage anything, not just containers.
Crossplane installs Custom Resource Definitions (CRDs) such as:
CompositeResourceDefinition (XRD)
Composition
Provider
ProviderConfig
Managed resource CRDs (e.g. RDSInstance, Bucket
Now Kubernetes understands new kinds of objects.
Crossplane has four major components:
Composition : Build custom APIs by composing Kubernetes resources