Traducciones al Español
Estamos 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.
Create a Linode account to try this guide with a $ credit.
This credit will be applied to any valid services used during your first  days.

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.

  1. 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.

  2. Following the official recommendations, this command installs Crossplane in its own Kubernetes namespace:

    helm install crossplane --namespace crossplane-system --create-namespace crossplane-stable/crossplane
  3. 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.

Warning
The configurations and commands used in this guide add one or more Linode instances to your account. Be sure to monitor your account closely in the Linode Cloud Manager to avoid unwanted charges.
  1. The provider allows you to deploy Akamai Cloud (formerly Linode) instances with Crossplane.

  2. 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.

  3. 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 list provider resources:

    kubectl get providers
    NAME              INSTALLED   HEALTHY   PACKAGE                                         AGE
    provider-linode   True        True      xpkg.upbound.io/linode/provider-linode:v0.0.7   15s
  4. 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 API

    • Replace ${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 .

  5. 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
  6. Verify that the instance has been deployed by using kubectl to fetch a list of instance 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:

A Linode Compute instance deployed with Crossplane.

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


Your Feedback Is Important

Let us know if this guide was helpful to you.


Join the conversation.
Read other comments or post your own below. Comments must be respectful, constructive, and relevant to the topic of the guide. Do not post external links or advertisements. Before posting, consider if your comment would be better addressed by contacting our Support team or asking on our Community Site.
The Disqus commenting system for Linode Docs requires the acceptance of Functional Cookies, which allow us to analyze site usage so we can measure and improve performance. To view and create comments for this article, please update your Cookie Preferences on this website and refresh this web page. Please note: You must have JavaScript enabled in your browser.