Crossplane: Cloud Infrastructure Manager Game Changer?

What is Crossplane?

As more and more organizations move their workloads to the cloud, the need for efficient and flexible management of cloud infrastructure is becoming increasingly important. Enter Crossplane, a promising open-source project that promises to revolutionize the way we manage cloud resources.

Crossplane is a powerful and game-changing tool in cloud infrastructure. It is designed to work with multiple cloud providers, allowing you to manage resources across different clouds in a consistent way. Built on top of Kubernetes, Crossplane leverages Kubernetes’ powerful features like declarative configuration, API-based management, and robust ecosystem of tools and plugins. In addition, Crossplane allows you to manage cloud resources using infrastructure-as-code (IaC) principles, and comes with a number of pre-defined custom resource definitions (CRDs) that can be used to define and manage complex systems composed of multiple resources.

In this blog post, we’ll explore what Crossplane is, how it works, deploy a simple RDS on AWS, and find out whether it really is a game changer in the world of cloud infrastructure. From its ability to abstract and unify different cloud providers to its support for a wide range of resources and its extensibility through custom resource definitions, Crossplane has the potential to dramatically simplify cloud infrastructure management and empower organizations to focus on delivering value to their customers. So, let’s dive in and explore what makes Crossplane such an exciting development in the world of cloud computing.

What are the best Crossplane features?

Crossplane is a powerful open-source Kubernetes add-on that lets you turn a Kubernetes cluster into a universal control plane. With its help we can widen our ability of creating, provisioning and managing cloud resources. This tool allows us to achieve high-level orchestration of our cloud infrastructure with minimal effort.

Crossplane has several core pillars such as packages, providers, managed resources and composite resources.

• A Package is a collection of resources, such as custom resource definitions (CRDs), controllers, and other Kubernetes objects, that work together to provide a specific set of functionality. Packages can be thought of as building blocks that can be used to create and manage cloud infrastructure. They can be found in a registry and installed by users. One can also create their own Packages to extend the Crossplane’s functionality.

• Different cloud providers let Crossplane be extensible, which means users can take advantage of the latest cloud-native technologies and services as soon as they become available.

• Crossplane manages resources across different cloud providers using the same API, so the users are able to create, update, delete and manage the infrastructure itself - no matter where it is run.

• Crossplane uses Composite Resources to design and build their own platform, or to create complex applications without writing underlying infrastructure.

What are the benefits of Crossplane?

• Developer-friendly API: Crossplane’s integration with Kubernetes makes it a natural choice for creating resources to request specific services. Furthermore, if you combine this tool with FluxCD you achieve DevOps best practice. We have a captivating post on how it is integrated with Cluster API: Cluster API: Create On-Demand Kubernetes Clusters Easily.

• Production-ready: Crossplane continuously reconciles the application, as a result when something breaks this tool will fix the state itself.

• Simplicity: With Crossplane, you can use a single tool to manage both the application and infrastructure resources. This reduces the number of tools and processes needed to manage your infrastructure, and eases the deployment process.

• You do not need to know how to code: With Crossplane you can build a control plane without deep knowledge of programming languages, since it is declarative which makes it highly configurable.

• Open Source: Being open source allows anyone to contribute to the development of Crossplane, creating a diverse community of developers and increasing transparency. This ultimately leads to faster development, greater innovation, and improved quality.

A simple Crossplane example

Deploying RDS on AWS with Crossplane is a fairly straightforward process, and the general steps are similar regardless of which database engine you choose (SQL Server, PostgreSQL, Aurora, etc.). However, in order to follow this showcase you need to install and configure some resources.

Prerequisites:

• Kubernetes cluster (if you do not have one just create it locally with Kind
• AWS CLI
• Upbound needs to be installed on the cluster (That is the newest version of Crossplane’s CRDs for AWS)
• AWS access key id and the key itself
• AWS account with the permissions to create RDS instance

Once you have installed Crossplane (Upbound), you will be asked to insert your AWS access and secret key in order to set up a connection to your AWS account.

By passing these credentials you let Crossplane communicate with your project. Next, you need to create a yaml Provider file that specifies the latest version of AWS provider CRDs. Here is an example:

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-aws
spec:
  package: xpkg.upbound.io/upbound/provider-aws:v0.31.0

Note: In this example one will see AWS specific CRDs, but it is worth mentioning that when you install Crossplane, it comes with a set of Kubernetes CRDs that enable you to define and manage cloud resources using Kubernetes manifests. These CRDs allow you to extend Kubernetes’ declarative model to include cloud infrastructure, making it easier to manage your cloud resources using familiar tools and workflows.

In addition to the CRDs specific to the AWS Provider, Crossplane also includes a set of core CRDs that are used by all providers. These include:

• ProviderConfig: This CRD is used to define the configuration for a provider in Crossplane. In the example provided earlier, the ProviderConfig is specific to AWS, and it defines the credentials and region to use when managing AWS resources.

• CompositeResourceDefinition: This CRD allows us to define a new custom resource that can represent a complex system composed of multiple resources. For example, we could define a custom resource that represents an entire Kubernetes cluster, along with all of the resources that it contains.

• CompositeResourceClaim: This CRD is used to claim and manage a specific instance of a CompositeResource. When a CompositeResourceClaim is processed, it creates a new instance of the corresponding CompositeResource.

• CompositeResource: This CRD is the actual instance of a CompositeResourceDefinition. When a CompositeResourceClaim is processed, it creates a new CompositeResource instance.

• Provider: This CRD is used to define and manage providers in Crossplane. Providers are the entities responsible for managing resources on behalf of the user.

By using CRDs in Crossplane, you can define and manage custom resources in a consistent and repeatable way, regardless of which cloud provider you’re using. This makes it easier to manage complex systems that span multiple cloud providers, and it also makes it easier to share and reuse custom resources across different projects and teams.

Now that we have Provider and credentials, we can start creating RDS instance by defining an RDSInstance resource. One of the main selling points of Crossplane is its ability to deploy cloud resources using Kubernetes resources. For example, Crossplane provides a set of custom resource definitions (CRDs) that can be used to deploy and manage Amazon Web Services (AWS) resources, such as RDS databases, S3 buckets, and EC2 instances, etc.

We are about to create Postgres (you can read more about RDS engine types) database with the version 13.7, allocated 20 GB of storage with “gp2” storage type. Update your values so that they match your needs. The username for the admin account is set to “admin”, and the password is retrieved from a secret named “password” in the “upbound-system” namespace. Overall, we have deployed a simple but functional RDS instance that can be used for hosting a Postgres database on AWS:

apiVersion: rds.aws.upbound.io/v1beta1
kind: Instance
metadata:
  name: example-dbinstance
spec:
  forProvider:
    allocatedStorage: 20
    autoMinorVersionUpgrade: true
    engine: postgres 
    engineVersion: "13.7"
    instanceClass: db.t3.micro
    maintenanceWindow: Mon:00:00-Mon:03:00
    name: example
    passwordSecretRef:
      key: password
      name: example-dbinstance
      namespace: upbound-system
    publiclyAccessible: false
    skipFinalSnapshot: true
    storageEncrypted: false
    storageType: gp2
    username: admin
  writeConnectionSecretToRef:
    name: example-dbinstance-out
    namespace: default

Note: To create an RDS instance with a MySQl or other available engine using Crossplane, you can simply change the engine field in the spec.forProvider section of this YAML file to mysql. Pay attention that the engineVersion field may need to be updated to the appropriate version for the selected engine type.

One of the most powerful features of Crossplane is that it allows you to deploy cloud resources using Kubernetes manifests. This means that you can define your entire infrastructure as code using Kubernetes resources, including your cloud resources. This approach provides several benefits, including declarative infrastructure management, consistency across environments, cloud-agnostic deployments, and simplified operations. By defining your infrastructure using Kubernetes manifests, you can use Kubernetes tooling to manage your cloud resources, reducing the learning curve and simplifying operations. This is both a significant selling point for Crossplane and it makes this add-on extremely powerful, as it allows you to manage all of your infrastructure using a single tool and a single set of processes.

Crossplane vs Terraform

It’s a common question, since one usually compares Crossplane to Terraform and yet it is not an “either .. or” one. Infrastructure as code (IaC) has become an essential part of modern cloud infrastructure management. It allows us to describe our infrastructure as a code (IaC), which can be versioned, tested, and deployed like any other software. Two popular IaC tools in use today are Terraform and Crossplane.

Both tools provide a way to manage cloud infrastructure resources declaratively, but they differ in their approach and features. There are some similarities between them, but nevertheless they have different approaches to the orchestration. Crossplane as it was mentioned before is a universal control plane, while Terraform offers developers CLI to interact with the control plane. In addition to that, it is possible to create an infrastructure where both Crossplane and Terraform are implemented. But shall we look at their differences in detail?!

Although Crossplane is a powerful tool for managing managed services, it also has some limitations:

• Moderate learning curve due to the complexity of the tool. One does need to know how to code, but Kubernetes knowledge is required.
• Limited integration with some cloud providers and managed services. For example: currently there are 3 times more CRDs for AWS than for GCP.
• Limited support for some complex use cases. There are not so many blogs and articles around Crossplane and the community is still growing.

Platform Engineer Final Thoughts on Crossplane

To sum up, Crossplane is a powerful and flexible tool for running infrastructure as code on Kubernetes. Its ability to manage a wide range of cloud resources and services in a consistent and automated manner makes it an attractive option for teams looking to simplify their infrastructure management.

While there are some drawbacks to using Crossplane, particularly in terms of its complexity and learning curve, these are outweighed by its benefits, such as its open-source nature and ability to integrate with existing Kubernetes workflows. Overall, Crossplane is a promising platform for managing infrastructure as code, and we can expect to see more organizations adopting it in the near future.

At Livewyer, we are open to new tools and technologies, as we believe they can improve our performance and ease our work, but moreover they are usually really fun to learn! We are planning to implement Crossplane-related solutions on our future projects, but this does not mean we will give up on Terraform - rather we found out that Crossplane could be more applicable for some cases, and vice versa.

Fun fact: Crossplane’s logo is a three-coloured ice lolly (or popsicle for our American friends). When asked about the meaning behind it they state they believe in a multi-flavour cloud. Bon appetit?