Ahead of KubeCon NA 2018, Upbound, creators of the Rook storage orchestrator for Kubernetes, have released Crossplane, an open source multi-cloud control plane that aims to provide a “universal API for cloud computing”. Crossplane exposes workload and resource abstractions on-top of Kubernetes and existing cloud-based managed services with the goal of enabling a high degree of workload portability across cloud providers.
A comprehensive “Introducing Crossplane” document — written by the Upbound team Bassam Tabbara, Illya Chekrygin and Jared Watts — argues that although the cloud computing model is now pervasive, it “remains completely under the control of a small set of cloud providers”. As explored previously on InfoQ, the authors also discusses that “while these cloud providers are themselves heavy adopters of open source technologies, cloud-computing remains predominantly proprietary and closed source”. Accordingly, running applications across multiple clouds with differing APIs and SDKs requires significant engineering effort.
The document states that there is exception to previous failed attempts at homogenising and integrating multi-cloud APIs, and this is Kubernetes, which “has always had a focus on workload portability, and defined a set of portable abstractions for running containers and their related networking and storage”. The Kubernetes community have recently focused on offering extension points for the framework, for example with Custom Resource Definitions (CRDs) and the creation of operators that support deployment and operational maintenance, but this often means that organisations are forced to run their own instance of data stores and middleware. Kubernetes also represents a small fraction of the workloads that many organisations are running in the cloud.
Upbound are presenting Crossplane as a “new portability layer on top of existing managed services and cloud offerings”. It introduces a set of workload and resource abstractions that build upon those provided by Kubernetes, and is based on project’s declarative resource management architecture. Crossplane uses the unmodified Kubernetes API server (kube-apiserver), etcd, and several of the core controllers. The documentation states that Crossplane can run directly on-top of an existing Kubernetes cluster without requiring any changes. Cloud vendors currently supported include: Google Cloud Platform, Microsoft Azure and Amazon Web Services.
Anyone familiar with Kubernetes resource definitions will instantly be familiar with Crossplane workloads definitions, and (outside of the initial cloud-specific environment configuration) within the examples provided the workloads are deployed with the Kubernetes ‘kubectl’ CLI tool. The example configuration YAML below, taken from the Crossplane documentation, shows a MySQL “dependency resource” and an excerpt from a WordPress “workload”:
## MySQL Database Instance apiVersion: storage.crossplane.io/v1alpha1 kind: MySQLInstance metadata: name: demo namespace: default spec: classReference: name: standard-mysql namespace: crossplane-system engineVersion: "5.7" ## WordPress workload apiVersion: compute.crossplane.io/v1alpha1 kind: Workload metadata: name: demo namespace: default spec: resources: - name: demo secretName: demo targetCluster: name: demo-gke-cluster namespace: crossplane-system targetDeployment: apiVersion: extensions/v1beta1 kind: Deployment metadata: name: wordpress labels: app: wordpress spec: selector: app: wordpress strategy: type: Recreate template: metadata: labels: app: wordpress spec: containers: - name: wordpress image: wordpress:4.6.1-apache [...]
The Crossplane documentation cautions that despite the obvious similarities, it should not be confused with Kubernetes. The two operate at different layers and solve different problems:
Kubernetes is a container orchestrator and is responsible for managing containers (pods), and the resources they consume (storage volumes, and networking) across a set of nodes. Crossplane is a multicloud workload and resource orchestrator and manages workloads (container, serverless, others) and resources they consume (databases, message queues, buckets, data pipelines, and others) across a set of cloud providers or on-premise environments.
Crossplane aims to be thought of as a “higher-order orchestrator” across cloud providers. It is appears to be similar to the federation project in Kubernetes, but is not limited to just containers and clusters.
A series of goals and non-goals are presented within the documentation. Goals include:
- Define a clean separation of concern between administrators and developers.
- Use existing managed services of a cloud provider.
- Use new cloud offerings from independent companies, like CockroachDB, Mongo, Confluent, Elastic and others that are not necessarily tied to a cloud provider.
- Enable full lifecycle management of resources via controllers.
- Expose rich extensibility points enabling others to easily build on-top of Crossplane.
Non goals include:
- Directly orchestrate container workloads on nodes (as Kubernetes already performs this task)
- Replace managed services in cloud providers.
- Improve the workflow of building, packaging, and deploying applications (there are already project focusing on this, including Skaffold and Garden.io)
- Define a packaging format for workloads or applications (related to this is the new “CNAB” format proposed recently by Docker, Microsoft and others)
The project documentation clearly states that this is an early access release, and no guarantees are made for production-readiness. Contributions from the community are being actively sought, and interested readers should visit the project GitHub repository or contact the Crossplane team.