Difficulty: intermediate
Estimated Time: 15-45 minutes

BoxBoat Logo

Welcome to the final section of Kubernetes Fundamentals II. In this lab, we will configure and deploy WordPress on Kubernetes using Helm. We previously did this as a challenge lab at the end of the first day. We'll start off where we left off, but now configure our applications using more advanced Kubernetes objects.

To find out more, visit here.

Kubernetes Fundamentals II - Advanced WordPress Lab

Step 1 of 6

Helm Charts

We've talked a lot about WordPress, now its time to deploy it. To do this we will be using the Helm package manager.

In the earlier Helm lab, we preconfigured some of the environment. Let's do that work here together, tying in some new concepts about permissions and service accounts:

  1. Create a ServiceAccount for Tiller, the part of Helm deployed in the cluster.

kubectl create serviceaccount --namespace kube-system tiller

  1. Create a ClusterRoleBinding called tiller-cluster-rule, giving it admin privileges within the cluster. Run a delete first, to ensure the ClusterRoleBinding is not in the environment already.

kubectl delete clusterrolebinding tiller-cluster-rule 2> /dev/null

kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

  1. Initialize Helm and Tiller: helm init

  2. Patch the existing Tiller deployment in the cluster to use the ServiceAccount we just created, and reinitialize our Helm client. kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'; helm init --client-only

A ServiceAccount is a special type of user in Kubernetes that our deployments can use. In the steps above, we create a user with administrator-level permissions cluster-wide, binding it to Tiller. For our lab environment this is fine, but in a production environment you may want to further restrict what permissions Tiller is granted.

For a deeper discussion on permissioning, check out the Kubernetes documentation on RBAC here.

Recall that Helm includes a default repository of charts, known as the stable repository, for use.

To search for any Wordpress charts in the stable repository:

helm search wordpress

Note that there is a chart listed as stable/wordpress, indicating that it is the wordpress chart within the stable repository.

Now let's download that chart for further examination by issuing a helm fetch:

helm fetch $(helm search wordpress | awk '{if (NR==2) print $1}') --destination ./resources --untar

We can inspect this chart by issuing a helm inspect command, passing in the chart's location:

helm inspect ./resources/wordpress

This command generates a very verbose output, consisting of the chart's Chart.yaml, values.yaml, and its README.md. Let's take a moment to go through the output, answering the following questions:

  • What values can I define for this chart?
  • What database is this chart deploying behind Wordpress to store its content?
  • Is there any ingress defined, and if so, what is it by default?
  • How would I change the database used?