GKE Series: HOWTO: WordPress : Using Kubernetes Engine to Deploy Apps with Regional Persistent Disks

Share This!

Creating the Regional Kubernetes Engine Cluster

Open a new Cloud Shell session. You will first create a regional Kubernetes Engine cluster that spans three zones in the us-west1 region. First, fetch the server configuration for the us-west1 region and export environment variables by running:

CLUSTER_VERSION=$(gcloud container get-server-config --region us-west1 --format='value(validMasterVersions[0])')
export CLOUDSDK_CONTAINER_USE_V1_API_CLIENT=false

Now create a standard Kubernetes Engine cluster (this will take a little while, ignore any warnings about node auto repairs):

gcloud container clusters create repd \
  --cluster-version=${CLUSTER_VERSION} \
  --machine-type=n1-standard-4 \
  --region=us-west1 \
  --num-nodes=1 \
  --node-locations=us-west1-a,us-west1-b,us-west1-c

Example Output:

Creating cluster repd...done.
Created [https://container.googleapis.com/v1beta1/projects/qwiklabs-gcp-e8f5f22705c770ab/zones/us-west1/clusters/repd].
To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/us-west1/repd?project=qwiklabs-gcp-e8f5f22705c770ab
kubeconfig entry generated for repd.
NAME  LOCATION  MASTER_VERSION  MASTER_IP      MACHINE_TYPE   NODE_VERSION  NUM_NODES  STATUS
repd  us-west1  1.12.6-gke.7    35.247.50.133  n1-standard-4  1.12.6-gke.7  3          RUNNING

You just created a regional cluster (located in us-west1) with one node in each zone (us-west1-a,us-west1-b,us-west1-c). Navigate to Compute Engine from the left-hand menu to view your instances:

k8s_instances.png

The gcloud command has also automatically configured the kubectl command to connect to the cluster.

Creating the Regional Kubernetes Engine Cluster

Deploying the App with a Regional Disk

Now that you have your Kubernetes cluster running, you’ll do the following three things:

  • Add the stable chart repository to Helm (a toolset for managing Kubernetes packages)
  • Create the Kubernetes StorageClass that is used by the regional persistent disk
  • Deploy WordPress

Add the Stable Chart Repo to Helm

The chart package, which is installed with Helm, contains everything you need to run WordPress.

Helm is pre-installed in Cloud Shell. You only need to add the stable chart repo which holds the WordPress chart.

  1. Add the stable chart repository:
helm repo add stable https://charts.helm.sh/stable
  1. Update the repo:
helm repo update

Create the StorageClass

Next you’ll create the StorageClass used by the chart to define the zones of the regional disk. The zones listed in the StorageClass will match the zones of the Kubernetes Engine cluster.

Create a StorageClass for the regional disk by running:

kubectl apply -f - <<EOF
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: repd-west1-a-b-c
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
  replication-type: regional-pd
  zones: us-west1-a, us-west1-b, us-west1-c
EOF

Example Output:

storageclass.storage.k8s.io/repd-west1-a-b-c created

You now have a StorageClass that is capable of provisioning PersistentVolumes that are replicated across the us-west1-aus-west1-b and us-west1-c zones.

List the available storageclass with:

kubectl get storageclass

Example Output:

NAME                 PROVISIONER            AGE
repd-west1-a-b-c       kubernetes.io/gce-pd   26s
standard (default)   kubernetes.io/gce-pd   1h

Create StorageClass

Create Persistent Volume Claims

In this section, you will create persistentvolumeclaims for your application.

Create data-wp-repd-mariadb-0 PVC with standard StorageClass.

kubectl apply -f - <<EOF
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: data-wp-repd-mariadb-0
  namespace: default
  labels:
    app: mariadb
    component: master
    release: wp-repd
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 8Gi
  storageClassName: standard
EOF

Create wp-repd-wordpress PVC with repd-west1-a-b-c StorageClass.

kubectl apply -f - <<EOF
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: wp-repd-wordpress
  namespace: default
  labels:
    app: wp-repd-wordpress
    chart: wordpress-5.7.1
    heritage: Tiller
    release: wp-repd
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 200Gi
  storageClassName: repd-west1-a-b-c
EOF

List the available persistentvolumeclaims with:

kubectl get persistentvolumeclaims

Example Output:

NAME                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       AGE
data-wp-repd-mariadb-0   Bound    pvc-8a10ed04-56ca-11e9-a020-42010a8a003d   8Gi        ROX            standard           21m
wp-repd-wordpress        Bound    pvc-ad5ddb0b-56ca-11e9-9af5-42010a8a0047   200Gi      ROX            repd-west1-a-b-c   20m

Create Persistent Volume Claim

Deploy WordPress

Now that we have our StorageClass configured, Kubernetes automatically attaches the persistent disk to an appropriate node in one of the available zones.

  1. Deploy the WordPress chart that is configured to use the StorageClass that you created earlier:
helm install wp-repd \
  --set smtpHost= --set smtpPort= --set smtpUser= \
  --set smtpPassword= --set smtpUsername= --set smtpProtocol= \
  --set persistence.storageClass=repd-west1-a-b-c \
  --set persistence.existingClaim=wp-repd-wordpress \
  --set persistence.accessMode=ReadOnlyMany \
  stable/wordpress

Deploy WordPress

  1. List out available wordpress pods:
kubectl get pods

Example Output:

NAME                                 READY     STATUS    RESTARTS   AGE
wp-repd-mariadb-79444cd49b-lx8jq     1/1       Running   0          35m
wp-repd-wordpress-7654c85b66-gz6nd   1/1       Running   0          35m  
  1. Run the following command which waits for the service load balancer’s external IP address to be created:
while [[ -z $SERVICE_IP ]]; do SERVICE_IP=$(kubectl get svc wp-repd-wordpress -o jsonpath='{.status.loadBalancer.ingress[].ip}'); echo "Waiting for service external IP..."; sleep 2; done; echo http://$SERVICE_IP/admin
  1. Verify that the persistent disk was created:
while [[ -z $PV ]]; do PV=$(kubectl get pvc wp-repd-wordpress -o jsonpath='{.spec.volumeName}'); echo "Waiting for PV..."; sleep 2; done

kubectl describe pv $PV
  1. Get the URL for the WordPress admin page :
echo http://$SERVICE_IP/admin
  1. Click on the link to open WordPress in a new tab in your browser.
  2. Back in Cloud Shell, get a username and password so you can log in to the app:
cat - <<EOF
Username: user
Password: $(kubectl get secret --namespace default wp-repd-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
EOF
  1. Go to the WordPress tab and log in with the username and password that was returned.

You now have a working deployment of WordPress that is backed by regional persistent disks in three zones.

Simulating a zone failure

Next you will simulate a zone failure and watch Kubernetes move your workload to the other zone and attach the regional disk to the new node.

  1. Obtain the current node of the WordPress pod:
NODE=$(kubectl get pods -l app.kubernetes.io/instance=wp-repd  -o jsonpath='{.items..spec.nodeName}')

ZONE=$(kubectl get node $NODE -o jsonpath="{.metadata.labels['failure-domain\.beta\.kubernetes\.io/zone']}")
IG=$(gcloud compute instance-groups list --filter="name~gke-repd-default-pool zone:(${ZONE})" --format='value(name)')
echo "Pod is currently on node ${NODE}"

echo "Instance group to delete: ${IG} for zone: ${ZONE}"

Example Output:

Pod is currently on node gke-repd-default-pool-b8cf37cd-bc5q
Instance group to delete: gke-repd-default-pool-b8cf37cd-grp for zone: us-west1-c

You can also verify it with:

kubectl get pods -l app.kubernetes.io/instance=wp-repd -o wide

Example Output:

NAME                                 READY     STATUS    RESTARTS   AGE       IP           NODE
wp-repd-wordpress-7654c85b66-gz6nd   1/1       Running   0          1h        10.20.0.11   gke-repd-default-pool-b8cf37cd-bc5q

Take note of Node column. You are going to delete this node to simulate the zone failure.

  1. Now run the following to delete the instance group for the node where the WordPress pod is running, click Y to continue deleting:
gcloud compute instance-groups managed delete ${IG} --zone ${ZONE}

Kubernetes is now detecting the failure and migrates the pod to a node in another zone.

  1. Verify that both the WordPress pod and the persistent volume migrated to the node that is in the other zone:
kubectl get pods -l app.kubernetes.io/instance=wp-repd -o wide

Example Output:

NAME                                 READY     STATUS    RESTARTS   AGE       IP           NODE
wp-repd-wordpress-7654c85b66-xqb78   1/1       Running   0          1m        10.20.1.14   gke-repd-default-pool-9da1b683-h70h

Make sure the node that is displayed is different from the node in the previous step.

  1. Once the new service has a Running status, open the WordPress admin page in your browser from the link displayed in the command output:
echo http://$SERVICE_IP/admin

You have attached a regional persistent disk to a node that is in a different zone.

Congratulations!  See additional Kubernetes Solutions below:

Qwiklabs Kubernetes Solutions

0 0 votes
Article Rating
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
trackback

[…] GKE Series: HOWTO: WordPress : Using Kubernetes Engine to Deploy Apps with Regional Persistent Disks […]

1
0
Would love your thoughts, please comment.x
()
x