Symbol Supply: crossplane.io
Despite the fact that Crossplane has been round for some time, I by no means were given round to attempting it. Crossplane has many features. Then again, on this put up, I can focal point at the following facets:
- Putting in Crossplane on a Kubernetes cluster (AKS); you’ll set up on an area cluster as smartly (e.g., k3s, sort, minikube, …) however then you could possibly want Azure Arc for Kubernetes to put in the microsoft.flux extension (I can be the use of GitOps with Flux by means of that extension)
- Including and configuring services for Azure and Kubernetes: services let you deploy to Azure and Kubernetes (and a lot more) from Crossplane
- Deploying Azure infrastructure with Crossplane the use of an absolutely declarative GitOps way
Advent
Crossplane mainly permits you to construct a keep an eye on airplane that you simply or your groups can use to deploy infrastructure and programs. This keep an eye on airplane is constructed on Kubernetes. In brief, assume I wish to deploy an Azure useful resource crew with Crossplane, I’d create the underneath YAML record and practice it with kubectl practice -f filename.yaml
.
That is, in essence, an absolutely declarative option to deploying Azure infrastructure the use of Kubernetes. There are different tasks, such because the Azure Service Operator v2, that do one thing an identical.
apiVersion: azure.jet.crossplane.io/v1alpha2
sort: ResourceGroup
metadata:
title: rg-crossplane
spec:
forProvider:
location: "westeurope"
tags:
provisioner: crossplane
providerConfigRef:
title: default
As a way to allow this capability, you want the next:
- Set up Crossplane in your Kubernetes cluster
- Upload a service that may create Azure assets; above the jet service for Azure is used; extra about services later
- Configure the service with credentials; on this case Azure credentials
Mixture with GitOps
Despite the fact that you’ll set up and configure Crossplane manually and simply use kubectl so as to add customized assets, I sought after so as to add Crossplane and customized assets the use of GitOps. To that finish, I’m the use of Azure Kubernetes Provider (AKS) with the microsoft.flux
extension. For more info to allow and set up the extension, see my Flux v2 fast information.
⚠️ The git repository I’m the use of with Flux v2 and Crossplane is right here: https://github.com/gbaeke/crossplane/tree/blogpost. This refers back to the blogpost department, which must fit the content material of this put up. Tbe primary department could be other.
The repo incorporates a number of folders that fit Flux kustomizations:
- infra folder: installs Crossplane and Azure Key Vault to Kubernetes; an infra kustomization will level to this folder
- secrets and techniques folder: creates a secret with Azure Key Vault to Kubernetes from Azure Key Vault; the secrets and techniques kustomization will level to this folder
- crossplane-apps folder: installs Azure assets and Kubernetes assets with the respective Crossplane services; the apps kustomization will level to this folder
Notice: should you have no idea what Flux kustomizations are and the way Flux works, do take a look at my Flux playlist: https://www.youtube.com/playlist?checklist=PLG9qZAczREKmCq6on_LG8D0uiHMx1h3yn. The movies have a look at the open supply model of Flux and now not the microsoft.flux extension. To be informed extra about that extension, see https://www.youtube.com/watch?v=w_eoJbgDs3g.
Putting in Crossplane
The infra customization installs Crossplane and Azure Key Vault to Kubernetes. The latter is used to sync a secret from Key Vault that incorporates credentials for the Crossplane Azure service. Extra main points are within the diagram underneath:
As famous above, the set up of Crossplane is completed with Flux. First, there’s the HelmRepository useful resource that provides the Crossplane Helm repository to Flux.
apiVersion: supply.toolkit.fluxcd.io/v1beta2
sort: HelmRepository
metadata:
namespace: config-infra
title: crossplane
spec:
period: 1m0s
url: https://charts.crossplane.io/strong
Subsequent, there’s the HelmRelease that installs Crossplane. Necessary: goal namespace is crossplane-system (base line):
apiVersion: helm.toolkit.fluxcd.io/v2beta1
sort: HelmRelease
metadata:
title: crossplane
namespace: config-infra
spec:
chart:
spec:
chart: crossplane
reconcileStrategy: ChartVersion
sourceRef:
sort: HelmRepository
title: crossplane
namespace: config-infra
set up:
createNamespace: true
period: 1m0s
targetNamespace: crossplane-system
For easiest effects, within the YAML above, set the namespace of the useful resource to the namespace you utilize with the AKS k8s-configuration. The assets to put in Azure Key Vault to Kubernetes are an identical.
To put in the Crossplane jet service for Azure:
---
apiVersion: pkg.crossplane.io/v1alpha1
sort: ControllerConfig
metadata:
title: jet-azure-config
labels:
app: crossplane-provider-jet-azure
spec:
symbol: crossplane/provider-jet-azure-controller:v0.9.0
args: ["-d"]
---
apiVersion: pkg.crossplane.io/v1
sort: Supplier
metadata:
title: crossplane-provider-jet-azure
spec:
package deal: crossplane/provider-jet-azure:v0.9.0
controllerConfigRef:
title: jet-azure-config
Above, debugging is became on for the service. That is not obligatory. The service in fact runs within the crossplane-system namespace:

The service is added by means of the Supplier useful resource (2d useful resource within the YAML manifest).
We will be able to now create the AKS k8s-configuration, which creates a Flux supply and a kustomization:
RG=your AKS useful resource crew
CLUSTER=your AKS cluster title (to put in Crossplane to)
az k8s-configuration flux create -g $RG -c $CLUSTER
-n cluster-config --namespace config-infra -t managedClusters
--scope cluster -u https://github.com/gbaeke/crossplane
--branch primary
--kustomization title=infra route=./infra prune=true
The Flux supply would be the repo specified with -u. There’s one kustomization: infra. Pruning is became on. With pruning, disposing of manifests from the repo effects is disposing of them from Kubernetes.
The k8s-configuration must lead to:

Crossplane is now put in with two services. We will be able to now configure the Azure service with credentials.
Configuring Azure Credentials
You want to create a provider most important via following the stairs in https://crossplane.io/medical doctors/v1.9/cloud-providers/azure/azure-provider.html. I compacted the ensuing JSON with:
cat <path-to-JSON> | jq -c
The output of the above command used to be added to Key Vault:

The Key Vault I’m the use of makes use of the Azure RBAC permission type. Make certain that the AKS cluster’s kubelet id has no less than the Key Vault Secrets and techniques Person function. This is a user-assigned controlled id with a reputation like clustername-agentpool.
To in fact create a Kubernetes secret from this Key Vault secret, the secrets and techniques folder within the git repo incorporates the manifest underneath:
apiVersion: spv.no/v2beta1
sort: AzureKeyVaultSecret
metadata:
title: azure-creds
namespace: crossplane-system
spec:
vault:
title: kvgebadefault # title of key vault
object:
title: azure-creds # title of the akv object
kind: secret # akv object kind
output:
secret:
title: azure-creds # kubernetes secret title
dataKey: creds # key to retailer object price in kubernetes secret
This creates a Kubernetes secret within the crossplane-system namespace with title azure-creds and a key creds that holds the credentials JSON.


So as to add the name of the game(s) as an additional kustomization, run:
RG=your AKS useful resource crew
CLUSTER=your AKS cluster title
az k8s-configuration flux create -g $RG -c $CLUSTER
-n cluster-config --namespace config-infra -t managedClusters
--scope cluster -u https://github.com/gbaeke/crossplane
--branch primary
--kustomization title=infra route=./infra prune=true
--kustomization title=secrets and techniques route=./secrets and techniques prune=true dependsOn=["infra"]
Notice that the secrets and techniques kustomization is depending on the infra kustomization. After operating this command, be certain the name of the game is within the crossplane-system namespace. The k8s-configuration makes use of the similar supply however now has two kustomizations.
Deploying assets with the Jet service for Azure
Sooner than explaining the right way to create Azure assets, a word on services. As a beginner Crossplane consumer, I began with the next Azure service: https://github.com/crossplane-contrib/provider-azure. This works smartly however it’s not so easy for members to make sure the service is up-to-date with the newest and largest Azure options. As an example, should you deploy AKS, you can not use controlled id, the cluster makes use of availability units and many others…
To reinforce this, Terrajet used to be created. This is a code era framework that may generate Crossplane CRDs (customized useful resource definitions) and units up the service to make use of Terraform. Development on best of Terraform is a bonus as a result of it’s extra up-to-date with new cloud options. That’s the reason why this put up makes use of the jet service. Once we later create an AKS cluster, it is going to make the most of controlled id and different more moderen options.
Notice: there could also be a Terraform service that may take Terraform HCL to do anything else you wish to have; we don’t seem to be the use of that on this put up
Adequate, let’s create a useful resource crew and deploy AKS. First, we need to configure the service with Azure credentials. The crossplane-apps folder incorporates a record referred to as jet-provider-config.yaml:
apiVersion: azure.jet.crossplane.io/v1alpha1
sort: ProviderConfig
metadata:
title: default
spec:
credentials:
supply: Secret
secretRef:
namespace: crossplane-system
title: azure-creds
key: creds
The above ProviderConfig tells the service to make use of the credentials within the Kubernetes secret we created previous. We all know we’re configuring the jet service from the apiVersion: azure.jet.crossplane.io/v1alpha1.
With that out of the best way, we will be able to create the useful resource crew and AKS cluster. Previous on this put up, the YAML to create the useful resource crew used to be already proven. To create a fundamental AKS cluster referred to as clu-cp on this crew, aks.yaml is used:
apiVersion: containerservice.azure.jet.crossplane.io/v1alpha2
sort: KubernetesCluster
metadata:
title: clu-cp
spec:
writeConnectionSecretToRef:
title: example-kubeconfig
namespace: crossplane-system
forProvider:
location: "westeurope"
resourceGroupNameRef:
title: rg-crossplane
dnsPrefix: "clu-cp"
defaultNodePool:
- title: default
nodeCount: 1
vmSize: "Standard_D2_v2"
id:
- kind: "SystemAssigned"
tags:
atmosphere: dev
providerConfigRef:
title: default
Above, we confer with our useful resource crew via title (resourceGroupNameRef) and we write the credentials to our cluster to a secret (writeConnectionSecretToRef). That secret will comprise keys with the certificates and personal key, but in addition a kubeconfig key with a legitimate kubeconfig record. We will be able to use that later to glue and deploy to the cluster.
To look an instance of connecting to the deployed cluster and making a namespace, see k8s-provider-config.yaml and k8s-namespace.yaml within the repo. The useful resource k8s-provider-config.yaml will use the example-kubeconfig secret created above to hook up with the AKS cluster that we created within the earlier steps.
To create a kustomization for the crossplane-apps folder, run the next command:
RG=your AKS useful resource crew
CLUSTER=your AKS cluster title
az k8s-configuration flux create -g $RG -c $CLUSTER
-n cluster-config --namespace config-infra -t managedClusters
--scope cluster -u https://github.com/gbaeke/crossplane
--branch primary
--kustomization title=infra route=./infra prune=true
--kustomization title=secrets and techniques route=./secrets and techniques prune=true dependsOn=["infra"]
--kustomization title=apps route=./crossplane-apps prune=true dependsOn=["secrets"]
This folder does now not comprise a kustomization.yaml record. Any manifest you drop in it is going to be implemented to the cluster! The k8s-kustomization now has the similar supply however 3 kustomizations:

After some time, an AKS cluster clu-cp must be deployed to useful resource crew rg-crossplane:

To mess around with this, I like to recommend the use of Visible Studio Code and the GitOps extension. When you’re making a transformation in the community and push to primary, to hurry issues up, you’ll reconcile the git repository and the apps kustomization manually:

Conclusion
On this put up, we checked out putting in and configuring Crossplane on AKS by means of GitOps and the microsoft.flux extension. As well as, we deployed a couple of Azure assets with Crossplane and its jet service for Azure. We best scratched the skin right here however I am hoping this will get you began briefly when comparing Crossplane for your self.