PLEASE NOTE: This document applies to v0.1 version and not to the latest release v0.2Documentation for other releases can be found by using the version selector in the top right of any doc page.
This section will walk you through how to deploy workloads to various cloud provider environments in a highly portable way. For detailed instructions on how to deploy workloads to your cloud provider of choice, please visit the following guides:
A workload is a schedulable unit of work and contains a payload as well as defines its requirements for how the workload should run and what resources it will consume. This helps Crossplane setup connectivity between the workload and resources, and make intelligent decisions about where and how to provision and manage the resources in their entirety. Crossplane’s scheduler is responsible for deploying the workload to a target cluster, which in this guide we will also be using Crossplane to deploy within your chosen cloud provider.
This walkthrough also demonstrates Crossplane’s concept of a clean “separation of concerns” between developers and administrators. Developers define workloads without having to worry about implementation details, environment constraints, and policies. Administrators can define environment specifics, and policies. The separation of concern leads to a higher degree of reusability and reduces complexity.
During this walkthrough, we will assume two separate identities:
Let’s take a closer look at a dependency resource that a workload will declare:
## WordPress 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"
This will request to create a
MySQLInstance version 5.7, which will be fulfilled by the
Note that the application developer is not aware of any further specifics when it comes to the
MySQLInstance beyond their requested engine version.
This enables highly portable workloads, since the environment specific details of the database are defined by the administrator in a
Now let’s look at the workload itself, which will reference the dependency resource from above, as well as other information such as the target cluster to deploy to.
## 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 env: - name: WORDPRESS_DB_HOST valueFrom: secretKeyRef: name: demo key: endpoint - name: WORDPRESS_DB_USER valueFrom: secretKeyRef: name: demo key: username - name: WORDPRESS_DB_PASSWORD valueFrom: secretKeyRef: name: demo key: password ports: - containerPort: 80 name: wordpress targetNamespace: demo targetService: apiVersion: v1 kind: Service metadata: name: wordpress spec: ports: - port: 80 selector: app: wordpress type: LoadBalancer
Workload definition contains multiple components that informs Crossplane on how to deploy the workload and its resources: