Anna | 14 March 2023
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.
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.
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. If you’d like to get acquainted with the current list of supported providers you can find them here.
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.
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 (we have a captivating showcase on how it is integrated with Cluster API), you achieve DevOps best practice.
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.
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.
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: This CRD is the actual instance of a CompositeResourceDefinition. When a
CompositeResourceClaim is processed, it creates a new
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 here) 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
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.
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
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?!
|Type of Tool||Infrastructure as Code||Infrastructure as a Managed Service|
|Deployment Target||Multi-cloud and On-premises||Multi-cloud and On-premises|
|Primary Functionality||Provisioning, Configuration, and Orchestration of Infrastructure||Automation and Management of Managed Services and Application Resources|
|Basic Use Case||Provisioning and Management of Infrastructure Resources and Deployments||Provisioning and Management of Managed Services, Containers, and Kubernetes Clusters|
|Declarative syntax||Yes, HCL||Yes, APIs and Controllers|
|Ease of Use||Easy to Learn and Use||Moderate Learning Curve due to its Abstraction of Complexities in Managed Services|
|Cross-Cloud Resource Management||No||Yes|
|Resource types||Wide range||Limited (they still work on it)|
|Community Support||Huge and Active Community||Growing Community|
|Integration with K8s||Requires external plugin||Native integration|
|Maturity||Mature, widely adopted||Emerging, growing|
Although Crossplane is a powerful tool for managing managed services, it also has some limitations:
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?
So what do you think about Crossplane? Let us know in the comments below!