Introduction to CrossPlane

Introduction

Crossplane is an open-source platform that enables the creation and management of cloud-native applications in a consistent and scalable manner. It provides a unified control plane for managing infrastructure, services, and applications across multiple cloud providers and on-premises environments. But what is a control plane, after all?

Explaining control planes

A control plane/data plane architecture consists in having one component to organize, manage and observe everything and another component which is, in fact, the “things” the control plane observes and manages. For better understanding, we can talk about an airport and aircrafts, where aircrafts are the data plane and the control tower for the airport is the control plane.

So we might say the data plane is the business value, and the control plane is the brain for it to work properly. When talking about the Platform Engineering world, we are already using applications everyone is aware of that work on control plane/data plane architecture. One of them is Istio Service Mesh which is used on Kubernetes Clusters for traffic management, telemetry, security and everything that is network-related.

As we can see, Istio has a control plane that is responsible for managing and configuring proxies to route traffic. The Istio data plane is composed of a set of (Envoy) proxies which are deployed as sidecars, being able to mediate and control all network communication between microservices.

Why CrossPlane

Now that we know the purpose of a control plane, you might be wondering: why Crossplane?

Imagine yourself as the Platform Team of a large company and being responsible for supporting multiple teams with infrastructure and architecture-related problems.

When a team requires an AWS S3 bucket or an Azure Storage Account, they must ensure that it meets security requirements, including disabled public access and safe storage of connection details.

I’m sure you’re thinking: it’s not a problem, I can handle it using Terraform!

It’s possible, and I’m also a Terraform lover, but scaling can make Terraform too difficult to manage, and we also put ourselves on the critical path of our Product Engineers.

Crossplane differs from Terraform in that it lets us extend Kubernetes’ Control Plane and create new APIs for our Product Engineers to interact with. They can create any resource they need, but we control which properties they can access and which they cannot.

Key Concepts

Managed Resources: Crossplane defines managed resources as any cloud or on-premises resource that can be created, managed, and updated through a declarative API.
Custom Resource Definitions (CRDs): CRDs are Kubernetes objects that define the schema and behavior of managed resources.
Controllers: Controllers are Kubernetes components that implement the desired state of managed resources by reconciling their actual state with the desired state defined in CRDs.
Provider: A provider is a component that abstracts the implementation details of a specific cloud provider or infrastructure platform.

Use Cases

Crossplane can be used in a variety of use cases, including:

Multi-Cloud Management: Manage infrastructure and applications across multiple cloud providers in a consistent manner.
Hybrid Cloud Management: Bridge the gap between cloud and on-premises environments by managing resources in both.
Application Lifecycle Management: Automate the deployment, scaling, and management of applications across different environments.
Infrastructure as Code: Define and manage infrastructure resources using declarative code, ensuring consistency and reproducibility.
Service Brokering: Provide a self-service portal for users to access and manage cloud services.

QuickStart with Azure

Prerequisites

This quickstart requires:

a Kubernetes cluster with at least 2 GB of RAM
permissions to create pods and secrets in the Kubernetes cluster
Helm version v3.2.0 or later
an Azure account with permissions to create an Azure Virtual Machine and Virtual Network
an Azure account with permissions to create an Azure service principal and an Azure resource group

Install Crossplane

Install the Crossplane Helm chart

helm repo add \
crossplane-stable https://charts.crossplane.io/stable
helm repo update

Install the Crossplane components using helm install.

helm install crossplane \
crossplane-stable/crossplane \
--namespace crossplane-system \
--create-namespace

Verify Crossplane installed with kubectl get pods.

$ kubectl get pods -n crossplane-system
NAME                                      READY   STATUS    RESTARTS   AGE
crossplane-d4cd8d784-ldcgb                1/1     Running   0          54s
crossplane-rbac-manager-84769b574-6mw6f   1/1     Running   0          54s

Install the Azure provider

cat <<EOF | kubectl apply -f -
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-azure-network
spec:
  package: xpkg.upbound.io/upbound/provider-azure-network:v0.42.1
EOF

Verify the provider installed with kubectl get providers.

$ kubectl get providers
NAME                            INSTALLED   HEALTHY   PACKAGE                                                  AGE
provider-azure-network          True        True      xpkg.upbound.io/upbound/provider-azure-network:v0.42.1   38s
upbound-provider-family-azure   True        True      xpkg.upbound.io/upbound/provider-family-azure:v0.42.1    26s

Create a Kubernetes secret for Azure

az ad sp create-for-rbac \
--sdk-auth \
--role Owner \
--scopes /subscriptions/

Save your Azure JSON output as azure-credentials.json

Create a Kubernetes secret with the Azure credentials

kubectl create secret \
generic azure-secret \
-n crossplane-system \
--from-file=creds=./azure-credentials.json

Create a ProviderConfig

A ProviderConfig customizes the settings of the Azure Provider. Apply the ProviderConfig with the command:

cat <<EOF | kubectl apply -f -
apiVersion: azure.upbound.io/v1beta1
metadata:
  name: default
kind: ProviderConfig
spec:
  credentials:
    source: Secret
    secretRef:
      namespace: crossplane-system
      name: azure-secret
      key: creds
EOF

This attaches the Azure credentials, saved as a Kubernetes secret, as a secretRef.

Create a managed resource

This example creates an Azure Virtual Network with Crossplane. The Virtual Network is a managed resource.

cat <<EOF | kubectl create -f -
apiVersion: network.azure.upbound.io/v1beta1
kind: VirtualNetwork
metadata:
  name: crossplane-quickstart-network
spec:
  forProvider:
    addressSpace:
      - 10.0.0.0/16
    location: "West Europe"
    resourceGroupName: myresourceGroup
EOF

Verify Crossplane created the Azure Virtual Network.

$ kubectl get virtualnetwork.network
NAME                            READY   SYNCED   EXTERNAL-NAME                   AGE
crossplane-quickstart-network   True    True     crossplane-quickstart-network   10m

Delete the managed resource

Use kubectl delete virtualnetwork.network to delete the virtual network.

$ kubectl delete virtualnetwork.network crossplane-quickstart-network
virtualnetwork.network.azure.upbound.io "crossplane-quickstart-network" deleted

Conclusion

As Crossplane continues to evolve, we can expect to see even more innovative use cases and integrations with other cloud-native technologies. Its open-source nature and active community ensure that Crossplane will remain a valuable tool for managing cloud-native applications and infrastructure for years to come.