Running highly available WordPress service with OpenEBS, the fastest open source storage for Kubernetes
In this guide, we will learn how to provide a shared storage (ReadWriteMany) solution on DigitalOcean Kubernetes platform for applications requiring access to the shared volumes. Here we are using WordPress to illustrate. To complete this solutions guide, all you need is a DigitalOcean Kubernetes cluster. MayaData has partnered with DigitalOcean to bring the OpenEBS project closer to DigitalOcean users through the DigitalOcean Marketplace.
Before we get into the details, let’s refresh our knowledge on available access modes in Kubernetes. A persistent volume can be mounted on a host in any way supported by the storage provider. Kubernetes storage providers have different capabilities, and each PV's access mode is set to the specific modes supported by that particular volume.
Access modes supported by Kubernetes are listed in the table below:
|
Access Modes |
Description |
|
ReadWriteOnce (RWO) |
The volume can be mounted as read-write by a single node. |
|
ReadOnlyMany (ROX) |
The volume can be mounted read-only by many nodes. |
|
ReadWriteMany (RWX) |
The volume can be mounted as read-write by many nodes. |
When we deploy a stateful application in a Kubernetes cluster, we create and access DigitalOcean Block Storage Volumes by creating a PersistentVolumeClaim (PVC) as part of our deployment using the default StorageClass named do-block-storage.
DigitalOcean Block Storage Volumes are mounted as read-write by a single node (RWO). Additional nodes can not mount the same volume; therefore, the data content of a PersistentVolume can not be accessed by multiple Pods simultaneously. Block storage is just like connecting a disk device/SSD to your host or VMs; unless you have a clustered file system on it or using Network File System (NFS), they can not be accessed by multiple nodes. DigitialOcean answered a similar question here.
Now let’s look into how we dynamically scale web servers and specifically content management systems (CMS) like WordPress or Magento on Kubernetes.
Kubernetes gives us orchestration capabilities to enable rapid scaling of applications on demand. Horizontal pod autoscaling (HPA) policies are used to scale the WordPress Pods in a dynamically StatefulSet. Increasing load triggers scheduling additional Pod replicas. As a result, Kubernetes schedules different Pods with the same data content as the other replicas. In this specific case, not only is the same content served by WordPress replicas, any update of the content, such as new images, user uploaded files, or plugins, need to be synchronously made available to the other replicas.
This is why WordPress requires a volume that can be mounted as read-write by many nodes (RWX), in our case, WordPress replica Pods.
NFS is a commonly used solution to provide RWX volumes on block storage. This server offers a PersistentVolumeClaim (PVC) in RWX mode so that multiple web applications can access the data in a shared fashion. In many cases, cloud block storage providers or OpenEBS volumes are used as persistent backend storage for these NFS servers to provide a scalable and manageable RWX shared storage solution.
OpenEBS Dynamic NFS Provisioner allows users to create an NFS PV that sets up a new Kernel NFS instance for each PV on top of the user's choice of backend storage.
We have compiled everything you need to get a scalable WordPress deployment up and running on DigitalOcean Kubernetes Service in this easy to follow Solution Guide.
Let us know how you use WordPress in production and also check out our deployment guides on common Kubernetes stateful workloads on our website.