PLEASE NOTE: This document applies to v0.2 version and not to the latest release v0.5
Documentation for other releases can be found by using the version selector in the top right of any doc page.This guide will walk you through how to use Crossplane to deploy a stateful workload in a portable way to GCP. In this environment, the following components will be dynamically provisioned and configured during this guide:
Before starting this guide, you should have already configured your GCP account for usage by Crossplane.
You should have a crossplane-gcp-provider-key.json
file on your local filesystem, preferably at the root of where you cloned the Crossplane repo.
This section covers the tasks performed by the cluster or cloud administrator, which includes:
Note: all artifacts created by the administrator are stored/hosted in the crossplane-system
namespace, which has
restricted access, i.e. Application Owner(s)
should not have access to them.
For the next steps, make sure your kubectl
context points to the cluster where Crossplane
was deployed.
Export Project ID
NOTE you can skip this step if you generated GCP Service Account using gcloud
export DEMO_PROJECT_ID=[your-demo-project-id]
Patch and Apply provider.yaml
:
sed "s/BASE64ENCODED_CREDS/`cat key.json|base64 | tr -d '\n'`/g;s/DEMO_PROJECT_ID/$DEMO_PROJECT_ID/g" cluster/examples/workloads/wordpress-gcp/provider.yaml | kubectl create -f -
Verify that GCP Provider is in Ready
state
kubectl -n crossplane-system get providers.gcp.crossplane.io -o custom-columns=NAME:.metadata.name,STATUS:.status.Conditions[0].Type,PROJECT-ID:.spec.projectID
Your output should look similar to:
NAME STATUS PROJECT-ID
gcp-provider Ready [your-project-id]
Verify that Resource Classes have been created
kubectl -n crossplane-system get resourceclass -o custom-columns=NAME:metadata.name,PROVISIONER:.provisioner,PROVIDER:.providerRef.name,RECLAIM-POLICY:.reclaimPolicy
Your output should be:
NAME PROVISIONER PROVIDER RECLAIM-POLICY
standard-cluster gkecluster.compute.gcp.crossplane.io/v1alpha1 gcp-provider Delete
standard-mysql cloudsqlinstance.database.gcp.crossplane.io/v1alpha1 gcp-provider Delete
Create a target Kubernetes cluster where Application Owner(s)
will deploy their WorkLoad(s)
As administrator, you will create a Kubernetes cluster leveraging the Kubernetes cluster ResourceClass
that was created earlier and
Crossplane
Kubernetes cluster dynamic provisioning.
kubectl apply -f cluster/examples/workloads/wordpress-gcp/cluster.yaml
Verify that Kubernetes Cluster resource was created
kubectl -n crossplane-system get kubernetescluster -o custom-columns=NAME:.metadata.name,CLUSTERCLASS:.spec.classReference.name,CLUSTERREF:.spec.resourceName.name
Your output should look similar to:
NAME CLUSTERCLASS CLUSTERREF
demo-gke-cluster standard-cluster gke-67419e79-f5b3-11e8-9cec-9cb6d08bde99
Verify that the target GKE cluster was successfully created
kubectl -n crossplane-system get gkecluster -o custom-columns=NAME:.metadata.name,STATE:.status.state,CLUSTERNAME:.status.clusterName,ENDPOINT:.status.endpoint,LOCATION:.spec.zone,CLUSTERCLASS:.spec.classRef.name,RECLAIMPOLICY:.spec.reclaimPolicy
Your output should look similar to:
NAME STATE CLUSTERNAME ENDPOINT LOCATION CLUSTERCLASS RECLAIMPOLICY
gke-67419e79-f5b3-11e8-9cec-9cb6d08bde99 RUNNING gke-6742fe8d-f5b3-11e8-9cec-9cb6d08bde99 146.148.93.40 us-central1-a standard-cluster Delete
To recap the operations that we just performed as the administrator:
Provider
with Google Service Account credentialsResourceClasses
for KubernetesCluster
and MySQLInstance
ResourceClass
This section covers the tasks performed by the application developer, which includes:
MySQL
databaseLet’s begin deploying the workload as the application developer:
Deploy workload
kubectl apply -f cluster/examples/workloads/wordpress-gcp/workload.yaml
Wait for MySQLInstance
to be in Bound
State
You can check the status via:
kubectl get mysqlinstance -o custom-columns=NAME:.metadata.name,VERSION:.spec.engineVersion,STATE:.status.bindingPhase,CLASS:.spec.classReference.name
Your output should look like:
NAME VERSION STATE CLASS
demo 5.7 Bound standard-mysql
Note: to check on the concrete resource type status as Administrator
you can run:
kubectl -n crossplane-system get cloudsqlinstance -o custom-columns=NAME:.metadata.name,STATUS:.status.state,CLASS:.spec.classRef.name,VERSION:.spec.databaseVersion
Your output should be similar to:
NAME STATUS CLASS VERSION
mysql-2fea0d8e-f5bb-11e8-9cec-9cb6d08bde99 RUNNABLE standard-mysql MYSQL_5_7
Wait for Workload
External IP Address
kubectl get workload -o custom-columns=NAME:.metadata.name,CLUSTER:.spec.targetCluster.name,NAMESPACE:.spec.targetNamespace,DEPLOYMENT:.spec.targetDeployment.metadata.name,SERVICE-EXTERNAL-IP:.status.service.loadBalancer.ingress[0].ip
Note the Workload
is defined in Application Owner’s (default
) namespace
Your output should look similar to:
NAME CLUSTER NAMESPACE DEPLOYMENT SERVICE-EXTERNAL-IP
demo demo-gke-cluster demo wordpress 35.193.100.113
Verify that WordPress
service is accessible via SERVICE-EXTERNAL-IP
by:
SERVICE-EXTERNAL-IP
At this point, you should see the setup page for WordPress in your web browser.
Once you are done with this example, you can clean up all its artifacts with the following commands:
Remove Workload
kubectl delete -f cluster/examples/workloads/wordpress-gcp/workload.yaml
Remove KubernetesCluster
kubectl delete -f cluster/examples/workloads/wordpress-gcp/cluster.yaml
Remove GCP Provider
and ResourceClasses
kubectl delete -f cluster/examples/workloads/wordpress-gcp/provider.yaml
Delete Google Project
# list all your projects
gcloud projects list
# delete demo project
gcloud projects delete [demo-project-id]