Crossplane - A more advanced cloud infrastructure management platform than Terraform?

👉️URL: https://crossplane.io/

📝Description:

Organize cloud infrastructure and services into custom platform APIs

Brief introduction

At the KCD Shanghai site in November, I listened to an introduction of Alibaba Cloud engineers about their own multi-cloud infrastructure management tools, the introduction section introduced Terraform, and another competitor is Crossplane, and said that Crossplane does better than Terraform in terms of generality APIs, and Alibaba Cloud also refers to its architecture and implementation. It intrigues me, and I also found Crossplane in its OperatorHub when I used OpenShift 4 in 2019, and I always had an impression when I thought its logo was very recognizable. So this time I took a weekend to try it out specifically to see if it deserved the title. Begin~

Crossplane (cross-plane, meaning it can span multiple public cloud platforms) is an open-source Kubernetes plugin that allows platform teams to assemble infrastructure from multiple vendors and expose higher-level self-service APIs to application teams without writing a single line of code.

vision

Power a more open cloud

Crossplane is built to help organizations build their clouds just as cloud vendors build their clouds – through a control plane. Crossplane is a CNCF project that extends the Kubernetes API to manage and compose infrastructure. Operators can encapsulate policies, permissions, and other guardrails behind a custom API line generated by Crossplane, while application developers can self-service from the API without having to be an infrastructure expert.

Benchmark products

Terraform

value

Here’s what it’s worth:

Use kubectl to provide and manage cloud infrastructure and services

Crossplane scales your Kubernetes cluster to provide you with a crd for any infrastructure or managed services. Combine these fine-grained resource groups into higher-level abstractions that can be versioned, managed, deployed, and used using your favorite tools or with existing processes already integrated into the cluster.

In Crossplane, everyone has their own infrastructure

Crossplane supports infrastructure from all major cloud providers, and the community is constantly developing new providers. The following mainstream public cloud providers are currently supported:

Provide a simplified infrastructure abstraction for your applications

Build your own internal infrastructure abstractions on top of what CRDs Crossplane provides. Your custom APIs can include policy guardrails that hide the complexity of the infrastructure and ensure that applications can use it safely.

Common cloud APIs

Crossplane provides a consistent API across different collections of vendors, resources, and abstractions. The Crossplane Resource Model (XRM) extends the Kubernetes Resource Model (KRM) in an arbitrary way, resulting in a unified resource management experience regardless of the vendor or vendor that builds them.

Run Crossplane anywhere

Whether you’re using a single Kubernetes cluster in EKS, AKS, GKE, ACK, PKS, or in a multi-cluster manager like Rancher or Anthos, Crossplane integrates them well. Crossplane can be installed into any existing cluster, exposing crds and standard APIs across infrastructure and service providers, making provisioning and management a breeze.

Why use Crossplane to manage applications and infrastructure?

🔘 Declarative infrastructure configuration

Crossplane brings Kubernetes-style declarative and API-driven configuration and management to any infrastructure, on-premises, and in the cloud. With this approach, infrastructure managed through Crossplane is accessible via kubectl, configurable using YAML, and instantly self-healing.

🔗 Unify the configuration and deployment of applications and infrastructure

Crossplane allows applications and infrastructure configurations to coexist on the same Kubernetes cluster, reducing the complexity of toolchains and deployment pipelines.

⚓️ A single source of truth for infrastructure configuration and setup

Crossplane integrates with CI/CD pipelines, so application infrastructure configurations are stored in a single control cluster. Teams can create, track, and approve changes using GitOps best practices already in use.

🔄 Use the Coordination Controller to automate operational tasks

The resource controller is responsible for the entire lifecycle of a resource. This resource is responsible for provisioning, health, scaling, failover, and actively responding to external changes that are inconsistent with the desired configuration.

➕ High level of scalability

Crossplane leverages the widely accepted Kubernetes pattern, which can be easily extended by adding its own APIs and controllers. Increase flexibility and security by packaging policies, quotas, and permissions into custom infrastructure definitions.

⇅ Strong separation of concerns

Developers can define workloads without worrying about implementation details, environmental constraints, or policies. Administrators can define environment details and policies. Support a higher degree of reusability and reduce complexity.

Crossplane vs Terraform

Crossplane is often compared to HashiCorp’s Terraform. The two projects have similarities:

• Both allow engineers to model their infrastructure as declarative configurations

• Both support the use of provider plugins to manage a large number of different infrastructures

• Both are open-source tools with strong communities

The key difference is that Crossplane is a control plane, while Terraform is a command-line tool — a control plane interface. The following touches on several pain points that enterprises often face when scaling Terraform, and highlights how Crossplane addresses them.

collaboration

Enterprises typically adopt Terraform through operations teams. Representing infrastructure as declarative configurations allows operations teams to benefit from best practices in software engineering – keeping configurations in revision control for peer review and recovery of changes if necessary.

When more engineers need to collaborate to manage their organization’s infrastructure, Terraform collapses. Terraform relies on a single state file to map the required configuration to the actual running infrastructure. There must be a lock on this state file when applying the configuration, and applying the Terraform configuration is a blocking process that can take several minutes to complete. During this time, no other entity—no other engineer—can make changes to the configuration. Similarly, Terraform uses a single one apply Processes – There is no recommended way to modify only one infrastructure in a configuration. If you use the same configuration to manage the cache and the database, you must always update them at the same time—you cannot update only the cache.

Terraform recommends breaking down individual configurations into increasingly fine-grained configurations. So while operations teams may start with a Terraform configuration that stands for “production,” they are encouraged to include it in scoped configurations such as “production billing” and “production auth.” This is difficult to do, so it can take a lot of refactoring time and often results in a complex grid-like Terraform configuration coupling its inputs and outputs.

The Crossplane Resource Model (XRM) promotes loose coupling and eventual consistency. In Crossplane, every part of the infrastructure is an API endpoint that supports create, read, update, and delete operations. Crossplane doesn’t require a computational dependency graph to make changes, so even if you use Crossplane to manage your entire production environment, you can easily operate on a single database.

Self-service

Modern organizations are moving from centralized infrastructure management to self-service models in which operations teams, often referred to as platform teams, define the infrastructure abstractions that the development teams they support can use on demand. Terraform has used modules (modules) to support this model. Modules are no different from software libraries. Like Crossplane, Terraform resources are high-fidelity representations of external API resources. Modules provide a simplified abstraction on top of the broader configuration of these resources — for example,RDS moduleAbstracts 8 different Terraform resources into a single “RDS instance” concept.

Treating application teams as consumers of Terraform’s configuration “library” means they are subject to Terraform’s collaborative constraints. Application developers are invited to collaborate on their organization’s infrastructure as if they were an operations team with a narrow focus. The platform team invites the application development team to share their workflow instead of providing them with a service. This meant that application teams had to learn a new, special-purpose toolset and language—Terraform and HashiCorp Configuration Language (HCL). It also raises the configuration abstraction level for application developers without increasing the level of access control abstraction. While platform teams can publish a module that allows application teams to manage “RDS instances”, access control is still at the cloud provider API level, so it revolves around “DB subnet groups” and “DB parameter groups”.

Crossplane’s equivalent of a Terraform module is a composite resource — an XR. Each XR is exposed as an API endpoint. Platform teams can define and document OpenAPI patterns for each XR (per API) and implement role-based access control (RBAC) at the API level. This means that if a platform team decides to abstract them and provide them to their development team, the AcmeCo PostgreSQL database, they can grant RBAC access to create, read, update, or delete an AcmeCo PostgreSQL database without having to manage access to various potential cloud concepts such as RDS instances or subnet groups. Because Crossplane is built on a battle-proven Kubernetes RBAC system, platform teams can easily support multiple application development teams within a single control plane. Each team can only be granted access to the abstractions they need — some teams may only be able to manage buckets, while others may be allowed to manage caches and databases.

In Crossplane, self-service is even larger because any one XR can offer multiple services. Crossplane decouples the input and output of XR (Kubernetes parlance for its spec and status) from its implementation, which is defined by Composition to describe. If application developers are granted permission to create AcmeCo PostgreSQL databases, they can easily choose from any class of services – any combination – and their platform team has declared compatibility with the said database. These service classes can represent production, staging, and development; AWS, Azure, and GCP; fast and slow; or any combination of both.

Integration and automation

Terraform has a lot of APIs, but it doesn’t provide its own. This has led many teams to commit their Terraform configurations into version control (git) and execute Terraform as part of their CI/CD pipeline. That’s an improvement over a team running Terraform on their laptops, but it exposes a key problem organizations face when trying to expand their use of Terraform. Terraform is a command-line tool — not a control plane. Because it is a short, one-time process, it will only try to coordinate the desired configuration with the actual infrastructure when it is invoked. Whether running from a CI/CD pipeline or from a laptop, Terraform is typically only called when engineers want the infrastructure to need an update.

Terraform’s conservative, “on-demand” approach, in harmony with the actual state of the infrastructure, can lead to new deadlocks. Recall that the process of applying the Terraform configuration is “all successes or all failures” — if you describe your cache and database in the same configuration, you must always update them at the same time. This means that if someone in your organization bypasses Terraform, the next person to trigger Terraform to run will face a surprising plan as he tries to undo the change. For example, consider a scenario where an engineer is called in the middle of the night to work on an event, makes some quick edits to the production cache configuration through the AWS console, and forgets to reflect those changes in Terraform. Infrastructure drift is so great that applying a Terraform configuration becomes a risky and daunting proposition is not unheard of.

Crossplane, on the other hand, is a series of long-running control loops. It constantly observes and corrects an organization’s infrastructure to match its desired configuration, whether or not changes are expected. This prevented the team from bypassing Crossplane. When Crossplane is asked to manage a piece of infrastructure, any changes made outside of that infrastructure are automatically and durably reverted.

An ongoing problem organizations face when using Terraform is that it doesn’t provide APIs. Integration with Terraform is a challenge because it is configured using Domain Specific Language (DSL) (HCL) and invoked by invoking command-line tools. Crossplane exposes REST APIs, the lingua franca for automation. Whether the team writes mainly shell scripts, mainly Python, or mainly writes Erlang common patterns, they can call REST APIs.

Crossplane does not expose any legacy REST APIs. Building on top of the Kubernetes API means teams can use tools like kubectl to orchestrate all of their infrastructure — cloud or otherwise. They use the same tools to orchestrate their containerized applications. Crossplane can even expose the details that applications need to connect to infrastructure as Kubernetes Secrets to simplify integration. It can be paired with projects such as ArgoCD, Gatekeeper, or Velero to enable GitOps, advanced policies, and backup. Need customized automation? Build your own Kubernetes Operator to integrate with Crossplane.

Both together?

Both Crossplane and Terraform can coordinate an organization’s infrastructure. There are similarities between the two, but each project is organized differently. Terraform provides a command-line interface to control plane APIs, and Crossplane itself is a control plane that can be used to build abstractions on other control planes. Because Crossplane enables platform teams to provide their own control plane, it avoids many of the challenges platform teams face when scaling Terraform.

Savvy readers may notice that these two projects can complement each other – Terraform is an interface to the control plane, and its Kubernetes provider allows orchestration of the Kubernetes control plane! This means that Terraform can be paired with Crossplane, for example, if your organization prefers HCL over YAML, your platform team can use Terraform to define xr and composition, and for your application team, Terraform to plan and apply changes to the desired state of Crossplane!

We think Crossplane is a great way for platform teams to help the developers they support self-serve their infrastructure needs.

Install the configuration

Users looking for more flexibility can install Crossplane into their own Kubernetes cluster.

Crossplane will use regularly released Helm Chart installations. The Helm chart contains all the custom resources and controllers needed to deploy and configure Crossplane.

Installing Crossplane into an existing Kubernetes cluster requires more setup, but provides more flexibility for users who need it.

precondition

• Kubernetes clusters
• Helm 3

Install Crossplane

kubectl create namespace crossplane-system

helm repo add crossplane-master https://charts.crossplane.io/master/
helm repo update
helm search repo crossplane-master --devel

helm install crossplane --namespace crossplane-system crossplane-master/crossplane \
  --devel --version <version>

Check the Crossplane status

helm list -n crossplane-system

kubectl get all -n crossplane-system

Install the Crossplane CLI

The Crossplane CLI extends kubectl’s capabilities to build, push, and install Crossplane packages:

curl -sL https://raw.githubusercontent.com/crossplane/crossplane/release-1.5/install.sh | CHANNEL=master sh

Select a starter configuration

Crossplane goes beyond simply modeling infrastructure primitives as custom resources—it enables you to define new custom resources using a pattern of your choice. We call them “composite resources” (XRs). Composite resource composition hosting resources — Kubernetes custom resources that provide high-fidelity representations of infrastructure primitives, such as SQL instances or firewall rules.

We use two special Crossplane resources to define and configure these new custom resources:

• One is CompositeResourceDefinition (XRD) It defines a new composite resource, including its schema. XRD can optionally provide a declaration (XRC).
• Composition Specify which resources the composite resources will consist of, and how they should be configured. You can create multiple Composition options for each composite resource.

XRD and Composition can be packaged and served as configuration Installation. Configuration is a combined configuration package, you can configure resources by creating a declarative one or using kubectl crossplane install configuration Easily install into Crossplane.

In the example below, we will install a configuration that defines a new one XPostgreSQLInstance XR and one accepts a single storageGB parameter PostgreSQLInstance XRC, and create a connection secret that contains the username, password, and key for the endpoint. Each provider has one Configuration, it can be satisfied PostgreSQLInstance。 Let’s get started!

Install the Configuration Package

If you want to know what this configuration package is and how to construct it before installing, skip toCreate a ConfigurationPart.

kubectl crossplane install configuration registry.upbound.io/xp/getting-started-with-aws:v1.5.1

Wait until all packages are healthy:

watch kubectl get pkg

Get the AWS account key file

To manage an RDS database using an AWS account:

AWS_PROFILE=default && echo -e "[default]\naws_access_key_id = $(aws configure get aws_access_key_id --profile $AWS_PROFILE)\naws_secret_access_key = $(aws configure get aws_secret_access_key --profile $AWS_PROFILE)" > creds.conf

Create a cloud provider secret

kubectl create secret generic aws-creds -n crossplane-system --from-file=creds=./creds.conf

Configure the cloud provider

We will create the following ProviderConfig object to configure credentials for AWS Provider:

apiVersion: aws.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
  name: default
spec:
  credentials:
    source: Secret
    secretRef:
      namespace: crossplane-system
      name: aws-creds
      key: creds

kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-1.5/docs/snippets/configure/aws/providerconfig.yaml

You have now configured support PostgreSQLInstance The Crossplane, now canProvide infrastructureFinish.

Provide infrastructure

Composite resources (XRs) are always cluster-wide — they exist outside any namespace. This allows XR to represent infrastructure that may come from several different namespaces. This is usually true for VPC networks - an infrastructure administrator might want to define a VPC network XR and a SQL instance XR, the latter of which may only be managed by application operators. Application operators can only use their team’s namespaces, but their SQL instances should all be connected to the VPC network managed by the infrastructure operators. Crossplane allows infrastructure operators to provide composite resource declarations (XRC) to their application operators (XRC,composite resource claim), so as to achieve such a scenario. XRC is the namespace proxy for XR; The schema of XRC is the same as that of its XR counterpart. When an application operator creates an XRC, a corresponding fallback XR is automatically created. This model is similar to that in KubernetesPersistent Volume (PV) and Persistent Volume Claim (PVC)similar

Declare infrastructure

We installed it in the previous section Configuration Pack:

• Define oneXPostgreSQLInstance XR。

• Provide a corresponding XR PostgreSQLInstance Statement (XRC).

• Create one that satisfies XR Composition。

This means that we can be in default Create one in the namespace PostgreSQLInstance XRC to provide a PostgreSQL instance and all the supporting infrastructure it might need (vpcs, firewall rules, resource groups, etc.)!

Note that the resource will create an RDS instance with your default VPC, which may or may not allow connections from the internet, depending on how it is configured.

apiVersion: database.example.org/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: my-db
  namespace: default
spec:
  parameters:
    storageGB: 20
  compositionSelector:
    matchLabels:
      provider: aws
      vpc: default
  writeConnectionSecretToRef:
    name: db-conn

kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-1.5/docs/snippets/compose/claim-aws.yaml

create PostgreSQLInstance Crossplane will begin offering a database instance on the cloud provider of your choice. Once the configuration is complete, you should see it in the output when you run itREADY: True:

kubectl get postgresqlinstance my-db

Note:

Waiting PostgreSQLInstance When you’re ready, you might want to review other resources in your cluster. You can view the Crossplane resource group with the following command:

• kubectl get claim: Gets all resources for all claim types, such as PostgreSQLInstance。
• kubectl get composite: Gets all composite types of resources, such as XPostgreSQLInstance。
• kubectl get managed: Gets all resources representing an external infrastructure unit.
• kubectl get <name-of-provider>: Get all resources related to the cloud provider.
• kubectl get crossplane: Get all Crossplane-related resources.

Try the following command to observe the resources you have ready:

kubectl get crossplane -l crossplane.io/claim-name=my-db

Once ready PostgreSQLInstance, you should be in default A namespace is seen that is named db-conn , which contains the key we defined in XRD. If they are made of composition filled, then they should appear:

$ kubectl describe secrets db-conn
Name:         db-conn
Namespace:    default
...

Type:  connection.crossplane.io/v1alpha1

Data
====
password:  27 bytes
port:      4 bytes
username:  25 bytes
endpoint:  45 bytes

Here I created an RDS, and the endpoint is:my-db-lfcp2-v792d.cbijsmocclgy.us-east-1.rds.amazonaws.com

Consumer infrastructure

Because connection secret information is written as Kubernetes secrets, they are easily used by Kubernetes primitives. The most basic building block in Kubernetes is pods. Let’s define a pod that will show us the database we can connect to the new provision.

apiVersion: v1
kind: Pod
metadata:
  name: see-db
  namespace: default
spec:
  containers:
  - name: see-db
    image: postgres:12
    command: ['psql']
    args: ['-c', 'SELECT current_database();']
    env:
    - name: PGDATABASE
      value: postgres
    - name: PGHOST
      valueFrom:
        secretKeyRef:
          name: db-conn
          key: endpoint
    - name: PGUSER
      valueFrom:
        secretKeyRef:
          name: db-conn
          key: username
    - name: PGPASSWORD
      valueFrom:
        secretKeyRef:
          name: db-conn
          key: password
    - name: PGPORT
      valueFrom:
        secretKeyRef:
          name: db-conn
          key: port

kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-1.5/docs/snippets/compose/pod.yaml

This one Pod Just connect to a PostgreSQL database and print its name, so if you run kubectl logs see-db, you should see the following output (or similar) after creating it:

 current_database
------------------
 postgres
(1 row)

clean

To clean up pods, run:

kubectl delete pod see-db

In order to clean up the prepared infrastructure, you can delete PostgreSQLInstance XRC:

kubectl delete postgresqlinstance my-db

When I do this, the corresponding Crossplane status is deleting：

$ kubectl get crossplane -l crossplane.io/claim-name=my-db
NAME                                                       READY   SYNCED   STATE      ENGINE     VERSION   AGE
rdsinstance.database.aws.crossplane.io/my-db-lfcp2-v792d   False   True     deleting   postgres   12.7      14m

Looking at the AWS console, it is also removing:

After the deletion is complete, the status of the 2 sides is also the same:

Next

Now you know how to supply and use complex infrastructure through combinations. atNext sectionon your Mac, you will learn how to write and package your own infrastructure APIs.

unload

See Uninstall docs for cleaning up resources, packages, and Crossplane itself.

summary

Combined with the previous chapter “Crossplane vs Terraform”, Crossplane does go a step further in cloud infrastructure management, and from the simple “quick start” link above, you can feel that Crossplane has advantages in these aspects compared to Terraform:

• 🔘 Declarative infrastructure configuration (Kubernetes in the same vein)
• 🔗 Unified application and infrastructure configuration and deployment (both in Kubernetes)
• 🔄 Use the Coordination Controller to automate operational tasks (This experience is really good)
• ⇅ Strong separation of concerns

Above.