Crossplane

This material is still under development

Before we begin, if you've just landed here, Crossplane is an IaC tool developed for Kubernetes. We declare what we want through yaml manifests for Kubernetes, and Crossplane with its respective Providers will work to transform the desired state into actual state. Unlike Terraform which has a statefile to store what was provisioned, Crossplane stores all information within Kubernetes' own ETCD, the Kubernetes object database.

There's no point in learning Crossplane without understanding Kubernetes. If you think you can do this, I'm sorry to say it won't be possible - perhaps you've arrived here too early. Come back later!

Crossplane is an open-source tool that is growing rapidly. Its purpose is to extend the Kubernetes API to create new control planes for managing the lifecycle of resources of any type, transforming Kubernetes into a universal controller. It allows you to manage anything, anywhere, all through standard Kubernetes APIs.

It's the missing power for your IDP, you can be sure.

Control planes constantly check whether intended resources exist, report when the intended state doesn't match reality, and act to correct differences. This is a fundamental principle of Kubernetes' declarative approach that Crossplane extends to external resources.

With Crossplane, platform teams can create new custom abstractions and APIs with all the power of Kubernetes policies, namespaces, and role-based access controls. Crossplane allows platform engineers to create custom APIs and abstractions by combining native Kubernetes resources and cloud resources under a single control plane.

We're leveraging the fact that the Kubernetes API is extensible and making it universal.

Github Crossplane

How Does Crossplane Work?

Through Custom Resources Definitions in Kubernetes, external resources to Kubernetes are created as native Kubernetes objects. This way, it's possible to use kubectl create and kubectl describe commands for these objects. For them, Crossplane will be the controller and will enforce the state of that resource.

To give you an idea, it's a kind of Terraform applied through Kubernetes, but with important differences:

Actually it's much more than that, as we can create abstractions for anything. Moving from API consumers to API providers.

• Crossplane is Kubernetes-native and uses its extensible API
• State management is done directly in the cluster's ETCD
• Enables more advanced abstractions through Compositions

Users only communicate with Kubernetes by defining resources using manifests, and Crossplane will be the controller communicating with external resources to deliver what was requested. The idea is to package everything the user wants to do by creating a Custom Resource for it and perform all necessary operations behind the scenes.

With custom APIs, users don't need to know details about underlying resources or requirements, just the details exposed by the platform.

Initial Concepts

Crossplane uses several core components to manage the various elements of creating and managing external resources through Kubernetes:

• Crossplane pods include the main Crossplane pod and the Crossplane RBAC manager pod. Together, these pods manage all Crossplane components and resources.

• Providers connect Kubernetes to any external provider, such as AWS, Azure, or GCP, similar to what Terraform does. Providers translate native Kubernetes manifests and API calls into external API calls. Providers are responsible for creating, deleting, and managing the lifecycle of their resources, being our point of connection with external systems.

• Managed resources are Kubernetes objects that represent resources that the Provider created outside Kubernetes. Creating a managed resource in Kubernetes requires a Provider to create a corresponding resource in the external system. Deleting a managed resource requires a Provider to delete the associated external resource.

• Compositions are templates of managed resources. Compositions describe more complex deployments, combining multiple managed resources and any necessary customizations. Don't think of this only as cloud resources, think bigger. Sometimes, to create a composition, we can use several different managed resources that use different providers. What's important is delivering to our user what they want through a simple request, hiding the complexity.

• Composite Resource Definitions represent a custom API, created by platform engineers and consumed by developers or end users. Composite resource definitions use an OpenAPIv3 schema to further extend Kubernetes with custom API endpoints, revisions, and much more.

  • Composite Resources represent all objects created by a user calling the custom API. Every time a user accesses the custom API, Crossplane creates a single Composite Resource and links all related managed resources to it.

  • If you noticed, what we really need to focus on to truly master Crossplane is compositions.

• Claims are like Composite Resources, but at the namespace level.

• EnvironmentConfigs are like Kubernetes ConfigMap. They're useful for custom resource mapping or for storing and retrieving data in Claims and Composite Resources.

• Usages define critical resources or custom dependency mappings. They can prevent Crossplane from deleting or can ensure a parent resource waits for Crossplane to delete all child resources first. It would be like Terraform's depends_on.

We also have the concepts of Package and ImageConfigs that will be covered in detail later.

Maintainers

Upbound is the company behind Crossplane development. It plays a fundamental role in the Crossplane ecosystem in several ways:

• Lead Maintainer leading Crossplane core development and contributing most of the code.
• Offers Upbound Cloud, a managed platform for Crossplane.
• Develops and maintains some official providers.
• Responsible for the Upbound Marketplace for provider distribution.
• Maintains official documentation.
• Coordinates the developer community.

Although Upbound is the main company behind Crossplane, the project is open source and part of the Cloud Native Computing Foundation (CNCF), allowing contributions from the global community.