Crossplane is an extension to Kubernetes, which transforms your Kubernetes cluster into a universal control plane. It allows you to manage anything that has an API available with the help of provider packages. It's also fully extendable, so you can build your own providers to support your APIs. Everybody likes 🍕 so here is a post providers-101-ordering-pizza-with-kubernetes-and-crossplane which goes through on a high level how to build a provider that is capable of ordering pizza for you inside Kubernetes cluster.
Crossplane is often used to interact with cloud providers like Azure, AWS, and GCP. By using the Crossplane, you can bring your infrastructure management to Kubernetes. Another significant benefit of Crossplane is that it acts as a Kubernetes Controller, constantly monitoring the state of external resources. So, if someone would modify/delete the resources outside of Kubernetes, Crossplane would reconcile the resources.
By connecting Kubernetes and the cloud provider APIs with Kubernetes Custom Resource Definitions (CRDs), Crossplane can be used to enable a Kubernetes-native approach to managing cloud resources. We can for example define a Database custom resource which will then provision a database in the cloud provider that we have hooked Crossplane into. This makes it easier for developers to start consuming infrastructure resources by hiding the complexity behind Crossplane compositions. The Ops team can create and maintain these compositions and the XRDs which define how the resource will look like for the consumers. Without going into too much detail, we could have a custom resource Database that the developers can consume.
apiVersion: storage.polarsquad.com/v1alpha1
kind: Database
metadata:
name: ps-demo-db-mysql
spec:
parameters:
name: ps-demo-db-mysql
size: "small"
Here, we define the size as small. The Ops team could set small, medium, and large options for the size. Then, in compositions, patch these values to specific instance types depending on the cloud platform. This also enhances the experience for the developers as they don't have to know the specific instance types.
As the resources are native Kubernetes manifests, you can bundle them with the other manifests you use to deploy the application to the cluster. When the resources are created, Crossplane will create the connection secrets to the application namespace for pods to consume.
Overall, the Crossplane allows you to form your own Cloud Platform inside Kubernetes. With the help of compositions, you can build a self-service platform where developers can easily create resources on-demand when they need them without having to jump through hoops to get additional backing services.
Throughout the series, I will be using the terms XRD,XR, and XRS. Here is a quick overview of what they stand for.
-
XRD- Composite Resource Definition -
XR- Composite Resource -
XRC- Claim
Prerequisites:
- Access to Google Cloud and gcloud cli
- Kubernetes cluster eg. minikube
- Helm
- Access to Aiven
Aiven offers a free tier so you can create an account and use it to get through the tutorial.
Install Crossplane
helm repo add crossplane-stable https://charts.crossplane.io/stable
helm install crossplane --namespace crossplane-system --create-namespace crossplane-stable/crossplane
At this point, the Crossplane is ready, and the next step is to install the needed Providers that give the Crossplane capabilities to provision managed resources to external systems.
In this series, we will provision resources to Google Cloud using the Google Cloud providers and, later in the series, leverage Terraform provider to manage resources that don't have a Crossplane native provider available yet.
Links to each part of this series:
Top comments (0)