TL;DR: Crossplane extends kubernetes from just being an application orchestrator to universal control plane for cloud infrastructure. This article can help you to understand what crossplane is and how it helps in provisioning the cloud resources in a declarative way in kubernetes.
Introduction: The problem spaceā ļø
Provisioning cloud resources has always been a key part of infrastructure management. In any organisational codebases, there would be many services co-existing and each service would have its databases, storage buckets, service accounts - often across multiple cloud providers like GCP, AWS or Azure.
For provisioning and managing these resouces, Infrastructure as Code (IaC) tools like terraform or cloudformative emerged which helped in bringing the structure and in defining infrastructure declaratively in configuration files. But they donāt continuously reconcile the actual state of your infrastructure.
Meanwhile, kubernetes reformed how we manage our applications and introduced the concepts of control planes that continuously ensures the actual cluster state matches the desired state defined by YAML manifests. I would assume that if you are giving this article a read you would have some basic understanding of how kubernetes worksš
It defines the objects(deployments and services) declaratively and 
ensures the system always matches our intent. And this intrigues the question that ā why canāt we manage cloud infrastructure in the same wayāļø
And here enters Crossplane which extends Kubernetesā model beyond container orchestration into the realm of infrastructure orchestration.
What Crossplane is and how it works?š¤
Crossplane is an abstraction layer that lets you provision and orchestrate cloud resources across multiple vendors in a declarative way using a single unified API.
It acts like an universal remote control for cloud services and along with this, brings 2 major advantages:
- Workload portability ā This allows dev teams to build applications that can run on any cloud provider without any modifications.
- Reconciliation loop ā This ensures that the state of your deployment matches the state of the configuration you passed in.
How to deploy āļø resources using crossplane?
Set up crossplane in kubernetes cluster
You can install Crossplane with Helm:
helm repo add crossplane-stable https://charts.crossplane.io/stable
helm repo update
helm install crossplane --namespace crossplane-system --create-namespace crossplane-stable/crossplane
Then verify:
kubectl get pods -n crossplane-system
Once itās running, Crossplane becomes part of your cluster ā ready to manage infrastructure.š
āŗ Install a Cloud Provider
Crossplane itself is cloud-neutral. You add providers for the clouds you want to manage.
For example, install the AWS provider:
kubectl crossplane install provider crossplane/provider-aws:v0.38.0
Similarly, you can install:
crossplane/provider-gcp
crossplane/provider-azure
Check your installed providers:
kubectl get providers
This step adds new CRDs (Custom Resource Definitions) like:
- S3Bucket
- RDSInstance
- VPC
āŗ Configure Provider Credentials
You need to give Crossplane permission to talk to your cloud account.
Example (AWS):
- Create a Kubernetes Secret with your AWS credentials:
kubectl create secret generic aws-creds -n crossplane-system --from-file=creds=./aws-credentials.conf
- Reference it in a ProviderConfig:
apiVersion: aws.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
  name: default
spec:
  credentials:
    source: Secret
    secretRef:
      namespace: crossplane-system
      name: aws-creds
      key: creds
This tells Crossplane how to authenticate when creating AWS resources.
āŗ Create a Cloud Resource (Example: AWS S3 Bucket)
Now, you can define a resource just like any other Kubernetes object.
apiVersion: s3.aws.crossplane.io/v1beta1
kind: Bucket
metadata:
  name: demo-bucket
spec:
  forProvider:
    locationConstraint: us-east-1
  providerConfigRef:
    name: default
Apply it:
kubectl apply -f bucket.yaml
Crossplaneās controller will:
- Connect to AWS using the credentials you provided,
- Create the bucket,
- Continuously reconcile its state.
Check its status:
kubectl get bucket
kubectl describe bucket demo-bucket
When you see Ready: True, your cloud resource is live š
āŗ Clean Up
When you delete the YAML manifest, Crossplane destroys the real cloud resource too:
kubectl delete -f bucket.yaml
Thatās full lifecycle management ā declarative and reversible.
Troubleshooting
The easiest way to check if your resources are properly deployed is to check the claim. You can do
kubectl get claim -n <namespace> 
If both synced and ready are true on your claim your resources should be deployed properly and ready for use. If any of them are false, firstly it could just be that it havenāt had enough time to deploy the resource, creating the resources can take some time, but if that is not the case then the most common place you could find info about potential errors is by describing the composite resource (not the claim) and looking at the events.
Hope you find this article insightful and if you want to explore more in this domain, you can always refer the crossplane documentation to dive deep into it.
 
 
              

 
    
Top comments (1)
Very well documented.Thanks