Kubernetes focuses on making it easier to work with containers at scale. Scalability is particularly important when working with Web applications which have multiple interdependent components, such as a Web application server, a database server and a file storage area. For these applications, it should be possible to scale each component separately without affecting functionality.
When scaling a Web application, users have a choice of different persistent storage types in Kubernetes: ReadWriteOnce (RWO), ReadOnlyMany (ROX) and ReadWriteMany (RWX). For a fully-scalable application, the RWX storage type is most suitable, since it allows pods running in different nodes to read and write to a common storage volume without conflict.
This guide walks you through the process of setting up RWX storage using the Kubernetes NFS provisioner and then deploys a Web application using this storage. It uses WordPress as an example, deploying it through the Bitnami WordPress Helm chart.
Assumptions and prerequisites
This guide makes the following assumptions:
- You have a multi-node Kubernetes cluster running with Helm and Tiller installed and without any existing NFS server provisioner.
- You have the kubectl command line (kubectl CLI) installed.
Step 1: Install the NFS Server Provisioner
If you already have an NFS server provisioner for your cluster, skip this step.
The first step is to install the NFS Server Provisioner. The easiest way to get this running on any platform is with the stable Helm chart. Use the command below, remembering to adjust the storage size to reflect your cluster's settings:
helm install stable/nfs-server-provisioner --set persistence.enabled=true,persistence.size=5Gi
Once installed, you should see output like that shown below:
Confirm that the NFS storage class is now available in your cluster by running the command below and verifying that you see nfs in the output:
kubectl get storageclass
Step 2: Configure and deploy a Web application
The Bitnami charts repository contains charts for many popular applications, and some of these charts come with built-in configuration support for NFS storage. This example uses the Bitnami WordPress Helm chart.
When installing the chart, configure the additional parameters needed for NFS persistent storage, as shown below. Remember to adjust the persistence.size parameter as needed, ensuring that it does not exceed the size set in Step 1:
helm install stable/wordpress --set persistence.accessMode=ReadWriteMany --set persistence.storageClass=nfs --set persistence.size=3Gi
You can also review the complete list of available chart parameters.
Once the deployment completes, follow the instructions shown and verify that you are able to access the WordPress administration panel by logging in with the auto-generated credentials.
Step 3: Test scalability
You can test that your WordPress deployment is in fact using NFS persistent storage as follows:
Check the PVC list and confirm that the NFS storage class is bound to the WordPress pod:
kubectl get pvc
Scale up the number of WordPress pods. Use the command below to scale the number of WordPress pods to 3, remembering to replace the DEPLOYMENT-NAME placeholder with the actual name of your WordPress deployment:
kubectl scale --replicas=3 deployment/DEPLOYMENT-NAME
Once the new pods are running, use the command below to watch the logs for each pod. You will need to repeat the command shown depending on the number of running pods, replacing the POD-NAME placeholder in each case with the correct pod name:
kubectl logs POD-NAME
Browse to different pages of the administration panel and make changes to the WordPress configuration while watching the pod logs. You will notice from the log output that your various HTTP/HTTPS requests are serviced by different pods of the cluster (and not all by the same pod). This demonstrates that the pods are able to independently serve requests while using the same persistent NFS storage area.
To learn more about the topics discussed in this guide, use the links below: