Product docs and API reference are now on Akamai TechDocs.
Search product docs.
Search for “” in product docs.
Search API reference.
Search for “” in API reference.
Search Results
 results matching 
 results
No Results
Filters
How to Use Crossplane
Traducciones al EspañolEstamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.
Crossplane offers an open-source extension to Kubernetes for creating a universal control plane. With Crossplane, you can orchestrate and manage your broader infrastructure entirely with Kubernetes tools. Crossplane can interface with just about any cloud platform API, including Akamai Cloud’s, and provides features like API abstractions and Kubernetes’s access control.
In this guide, you learn more about what Crossplane is and how it compares to similar tools. You can also follow step-by-step instructions to set up your own Crossplane instance.
What Is Crossplane?
Crossplane creates cloud control planes across conceivably any cloud platform. Crossplane extends Kubernetes into a universal control plane. With it, you can provision and manage your broader infrastructure needs using familiar Kubernetes manifests and APIs.
Crossplane’s extension of Kubernetes as a universal control plane lets it interface with virtually any external API. That is the case whether you are deploying to a major cloud platform, ordering a pizza , or leveraging another orchestration tool like Terraform .
What Are Control Planes?
In the context of cloud resources, a control plane provides an interface to create resources and manage their lifecycles. A control plane thus corresponds with resource orchestration for cloud infrastructures.
Kubernetes itself is an example. A Kubernetes setup deploys and monitors resources, managing the state of each resource toward a given configuration.
Crossplane takes the Kubernetes control plane and extends it to a wider context. Whereas Kubernetes acts as a control plane for resources on a Kubernetes cluster, Crossplane acts as a universal control plane. Crossplane can be the interface for resources on virtually any cloud platform.
Crossplane vs. Terraform: What Are the Differences?
Terraform stands as perhaps the most popular tool for infrastructure-as-code. Like Crossplane, Terraform lets you manage that infrastructure across a range of services. So what sets Crossplane apart from Terraform, and when should you use Crossplane instead of Terraform?
Fundamentally, the differences come down to the tool’s intended uses. Terraform is a command line tool for deploying infrastructure using declarative configurations. By contrast, Crossplane is a control plane that uses declarative configurations for creating and providing ongoing management of infrastructure.
Additionally, two significant functional differences stand out between the tools. These differences primarily affect how the tools fit into an organization and team structure.
Terraform’s configurations do not update with changes on the deployed infrastructure. Terraform is oriented around deploying infrastructure, and changes to a Terraform configuration require reapplying the whole deployment.
As a control plane, Crossplane uses its declarative configurations to actively maintain and modify the state of infrastructure. This means that Crossplane is not subject to the configuration “drift” that can occur with Terraform configurations.
With Terraform, a collaborating developer needing some infrastructure access has to know both Terraform and the underlying API. Not only that, but the developer also needs granular access to the underlying resources.
In contrast, Crossplane can provide self-service interfaces. Crossplane uses operators that handle credentials and expose simple, abstracted interfaces for collaborating developers. That way, developers only need access to and knowledge of the interface itself, rather than the granular aspects.
Crossplane’s use of Kubernetes also makes it a favorable solution for teams already using Kubernetes. Crossplane takes advantage of the existing Kubernetes infrastructure and familiarity.
How to Install Crossplane
Crossplane deploys to a Kubernetes cluster similar to many other Kubernetes applications. Once you have Crossplane installed on your cluster, you can take advantage of kubectl
to create and manage Crossplane resources.
Follow along with the steps in this section to set up a Kubernetes cluster and get Crossplane running on it.
Setting Up a Kubernetes Cluster
Crossplane runs on a Kubernetes cluster, so you need a running cluster available to get started with it.
With Linode, you can quickly deploy a Kubernetes cluster from the Cloud Manager. To do so, follow along with our guide Linode Kubernetes Engine - Getting Started
. When done, you should have a fully operational Kubernetes cluster and a kubectl
instance configured to manage it.
In addition to having an active Kubernetes cluster, you need kubectl configured to manage it. You can find this information covered in the LKE guide linked just above.
To install Helm on your system, follow the relevant section of our guide Installing Apps on Kubernetes with Helm 3 .
Deploying Crossplane with Helm
With Kubernetes running and Helm installed, you can now proceed to install Crossplane.
Add the Crossplane repository to your Helm instance:
helm repo add crossplane-stable https://charts.crossplane.io/stable helm repo update
Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "crossplane-stable" chart repository Update Complete. ⎈Happy Helming!⎈
Should you want to customize your installation, follow the link above to create a values file with the options and name it
values.yml
for this example. Then add-f values.yml
to the end of the installation command below to apply your configuration to the installation.Should you want to customize your installation, follow the link above to create a
values.yaml
file with the options. Then add-f values.yml
to the end of the installation command below to apply your configuration.Following the official recommendations, this command installs Crossplane in its own Kubernetes namespace:
helm install crossplane --namespace crossplane-system --create-namespace crossplane-stable/crossplane
Confirm the installation by checking on the Crossplane pods deployed to your cluster. It may take a short while for the pods to become ready, so you may have to wait to see the
Running
status.kubectl get pods --namespace crossplane-system
NAME READY STATUS RESTARTS AGE crossplane-766d6647bc-b57lz 1/1 Running 0 44s crossplane-rbac-manager-f94699c7c-zvvtb 1/1 Running 0 44s
How to Use Crossplane
Crossplane is now running on your cluster, and you are ready to start using its control planes to deploy your own infrastructure. There are myriad options available, as Crossplane is a universal control plane with the ability to control an almost limitless range of external APIs.
To get started, this section walks through a fully-functioning example. The example shows how to use the Linode provider for Crossplane to deploy a new Linode Compute instance.
While relatively simple, this example provides a strong base model. You can easily build on the configurations here to make Crossplane work for a diverse range of infrastructure needs.
The provider allows you to deploy Akamai Cloud (formerly Linode) instances with Crossplane.
Create a deployment manifest (e.g.
provider.yml
) for installing the Linode provider (provider-linode
) to your Crossplane instance:- File: provider.yml
1 2 3 4 5 6
apiVersion: pkg.crossplane.io/v1 kind: Provider metadata: name: provider-linode spec: package: xpkg.upbound.io/linode/provider-linode:v0.0.10
See the wide range of providers available for Crossplane on the Upbound Marketplace . Upbound are the founders of Crossplane, and they maintain this provider repository.
Apply the newly created manifest to install
provider-linode
onto the Kubernetes cluster:kubectl apply -f provider.yml
provider.pkg.crossplane.io/provider-linode created
Verify the installation with a
kubectl
command to listprovider
resources:kubectl get providers
NAME INSTALLED HEALTHY PACKAGE AGE provider-linode True True xpkg.upbound.io/linode/provider-linode:v0.0.7 15s
Create a Kubernetes manifest file (e.g.
deployment.yml
) for deploying a new Linode Compute instance. This is where you start leveraging Crossplane and the Linode provider to provision resources.In this example manifest, you need to replace a few values with ones specific to your needs and your Linode account credentials:
Replace
${ROOT_PASSWORD}
with a root password to be used for the new Linode Compute instance.Replace
${LINODE_API_TOKEN}
with your Linode API personal access token, which you can generate by following the relevant section of our guide on Getting Started with the Linode APIReplace
${SSH_PUBLIC_KEY}
with a public SSH key to access the Linode Compute instance. Learn more about SSH keys in our guide Using SSH Public Key Authentication .
- File: deployment.yml
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
apiVersion: v1 kind: Secret metadata: name: crossplane-secrets namespace: crossplane-system type: Opaque stringData: linodeRootPass: ${ROOT_PASSWORD} linodeCredentials: | { "token": "${LINODE_API_TOKEN}" } --- apiVersion: linode.upbound.io/v1beta1 kind: ProviderConfig metadata: name: default spec: credentials: source: Secret secretRef: name: crossplane-secrets namespace: crossplane-system key: linodeCredentials --- apiVersion: instance.linode.upbound.io/v1alpha1 kind: Instance metadata: annotations: meta.upbound.io/example-id: instance/v1alpha1/instance labels: testing.upbound.io/example-name: web name: web spec: forProvider: authorizedKeys: - ssh-rsa ${SSH_PUBLIC_KEY} image: linode/ubuntu20.04 type: g6-standard-1 label: crossplane-deployment-example region: us-southeast rootPassSecretRef: key: linodeRootPass name: crossplane-secrets namespace: crossplane-system
This manifest consists of three parts, which perform these functions:
The
Secret
resource (crossplane-secrets
) stores variables for your instance’s root password and your Linode API token. Later resources can then use these.The
ProviderConfig
resource provides initial configurations to be used by the upcoming resource. For the Linode provider, that simply means pointing to the secret value with the Linode API token.The
Instance
resource (web
) articulates the details of the new Linode Compute instance to be created. This example creates a 2GB shared instance in Atlanta running Ubuntu 20.04 LTS.Use the API endpoints to learn more about available instance types , regions , and images .
Apply the deployment manifest in the same manner as deploying standard resources to a Kubernetes cluster:
kubectl apply -f deployment.yml
secret/crossplane-secrets created providerconfig.linode.upbound.io/default created instance.instance.linode.upbound.io/web created
Verify that the instance has been deployed by using
kubectl
to fetch a list ofinstance
resources:kubectl get instances
At first, you should see output like this, indicating that the instance provisioning has not yet completed:
NAME READY SYNCED EXTERNAL-NAME AGE web False True 33s
Wait a short while and try the command again, and you should see the instance become
READY
, indicating that your Compute instance has been successfully provisioned.NAME READY SYNCED EXTERNAL-NAME AGE web True True 45521497 2m46s
Further verify the successful deployment through the Linode Cloud Manager. Navigate to the Linodes section, and you should see the new Compute instance listed. Using the example deployment.yml
above, the new instance would be named crossplane-deployment-example
, as shown here:
Conclusion
With that, you have everything set up to start using Crossplane for as a universal control plane. Deploying the Linode instance in the example above shows you the basics of Crossplane’s infrastructure management. And exploring with that deployment manifest can give you more ideas about how Crossplane manages its infrastructure.
Crossplane is also a highly flexible tool and has features to accommodate a wide variety of infrastructure needs. One valuable area to explore is actually Kubernetes’s role-based access control (RBAC) features. Crossplane can utilize these robust access-control features for its control planes, too.
To learn more about the concepts behind your Crossplane instance, take a look at Crossplane’s introduction documentation. This covers some of the most important concepts for making the most of your control planes. And for more information, follow the link below to the full Crossplane documentation.
More Information
You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.
This page was originally published on