While you may never have a reason to deploy WordPress on CaaSP, the following exercise will give you a way to see how persistent storage, deployments, and NodePort networking work in Kubernetes work. It is my belief that a decent understanding of the theory around Kubernetes is useful, but an actual hands-on understanding will help fill in gaps where theory alone misses. It is assumed that you have already built your own cluster and have kubectl working. Example files are on Github and are free to download.
The persistent storage strategy that we will be using example below uses NFS as the Persistent Volume (pv). An example /etc/exports is below.
It’s important that the CaaSP cluster be allowed to access the NFS share and that no_root_squash be enabled as the Persistent Volume will be writing to the NFS share as root.
NFS-volumes.yaml is where persistent data for the WordPress installation will reside. The PV mounts the NFS shares. The file is in yaml format which means that spaces are important and never use tabs. Edit this file to point to two separate NFS shares and then you can deploy it.
kubectl create -f NFS-volumes.yaml
The MySQL database needs a root password in order to be started. We create a secret in Kubernetes that the MySQL deployment can pick up and apply to the new MySQL Pod.
kubectl create secret generic mysql-pass --from-literal=password=YOUR_PASSWORD
The MySQL Deployment has three parts. They are the Service, the Persistent Volume Claim (PVC), and the Pod deployment.
kubectl create -f mysql-deployment.yaml
The Service is the networking element of the deployment. It allows WordPress to connect to MySQL on port 3306.
Persistent Volume Claim
The PVC connects to the PV that we created previously. When the PVC is created successfully, the PV will be bound to it and persistent files will be able to be written to the NFS share that the PV is based on.
A Pod will be created from the mysql:5.6 image pulled from hub.docker.com and put into a container. Containers in the Kubernetes world are called Pods.
The WordPress Deployment is very similar to the MySQL deployment. However, we will need to be able to access WordPress, the application from the outside. In the service section of the wordpress deployment file, we see that the service type is NodePort. This is important to note because with this, we can access the installation from outside.
kubectl create -f wordpress-deployment.yaml
The following section will review all of the parts of a successfully installed WordPress deployment using the steps above.
Review Persistent Volumes
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
local-pv-1 20Gi RWO Retain Bound default/wp-pv-claim 2h
local-pv-18 20Gi RWO Retain Bound default/mysql-pv-claim 2h
$ kubectl get secrets
NAME TYPE DATA AGE
mysql-pass Opaque 1 2h
Review Persistent Volume Claims
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mysql-pv-claim Bound local-pv-18 20Gi RWO 2h
wp-pv-claim Bound local-pv-1 20Gi RWO 2h
$ kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
wordpress NodePort 172.24.11.97 <none> 80:30941/TCP 2h
wordpress-mysql ClusterIP None <none> 3306/TCP 2h
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
wordpress-db8f78568-n45nv 1/1 Running 0 2h
wordpress-mysql-7b4ffb6fb4-9r8tl 1/1 Running 0 2h
Accessing Your Deployment
In the section on the WordPress deployment, I mentioned that our WordPress service will use NodePort. In the section where we reviewed the services, we see that NodePort type for WordPress and that it is listening on ports 80:30941. This means that WordPress is looking for traffic to come in on port 80 but our cluster will actually be listening on port 30941. Find the IP of any of your worker nodes and combine that with your NodePort port to access your new WordPress deployment. Example: http://192.168.0.1:30941.
This guide is an adaption from the Kubetnetes.io’s Deploying WordPress and MySQL with Persistent Volumes which was produced under a Creative Commons Attribution 4.0 license.