Deploying WordPress on Kubernetes Clusters


In this tutorial, you will be guided on how to deploy WordPress on Kubernetes platforms. The instruction can be used for any Kubernetes cluster, whether it is on-premise, GKE (Google Kubernetes Engine), AKS (Azure Kubernetes Service), or EKS (Elastic Kubernetes Service).

The first section of this tutorial will show you how to launch your first WordPress instance in Kubernetes.

Kubernetes Pods

Kubernetes runs containers within a construct called a pod, which are the smallest atomic unit of a Kubernetes cluster. All containers run within a Kubernetes pod, but a container does not equal a pod.

Each pod provides a single, shared namespace for networking and storage. Multiple containers may run within a single pod, where each container will have access to the same networking namespace and storage. And while multiple containers may run within a single pod, it is best practice for each application being deployed to Kubernetes to have its own pod.

You may be asking yourself why allow running multiple containers within a single pod if it isn’t best practice. The answer to the question is this allows us to attach utility containers to our pods, such as log aggregators, for example.

For a pod to start successfully all containers within it must execute successfully. If your application container starts, but your logging or application monitoring container fails, the pod will not transition to a running state.

Creating a WordPress Pod

To create our first WordPress pod you will need to create a declarative configuration in YAML. The configuration if declarative because we are instructing Kubernetes to set the desired state for our pod.

Create a YAML file named wordpress-blog.yml

apiVersion: v1
kind: Pod
  name: wordpress-blog
  - name: wordpress-blog
    image: wordpress:5.2
      value: wordpress
      value: myblog_ 

Create the configuration in Kubernetes

kubectl create -f wordpress-blog.yml

The output of the create command will display the status of your request, so will know right away if the pod was created successfully or not. To list your running pods you will use the kubectl get command.

kubectl get pods

The output will look similar to the following, depending on how many pods are running in your cluster and which Kubernetes namespace you are querying against.

 wordpress-blog   1/1     Running   0          65s

Getting Pod Details

The kubectl get command will only show you basic information about your pods. For a detailed look at the configuration and state of your pod you will use the kubectl describe command.

kubectl describe pods wordpress-blog
Name:               wordpress-blog
 Namespace:          default
 Priority:           0
 Node:               worker/
 Start Time:         Sat, 18 May 2019 06:38:16 -0400
 Status:             Running
     Container ID:   docker://f9b860f167fb990992cc4c0d57e51f7934bb58cd377848e0cbf90dfc4d0fc42b
     Image:          wordpress:5.2
     Image ID:       docker-pullable://wordpress@sha256:8eb650ebbc8ea8bf743e046967c06a789c43c4baa46252013faf3c6f5ddd0d58
     Host Port:      
     State:          Running
       Started:      Sat, 18 May 2019 06:38:18 -0400
     Ready:          True
     Restart Count:  0
       WORDPRESS_DB_NAME:    wordpress
       WORDPRESS_DB_PREFIX:  myblog_
       /var/run/secrets/ from default-token-x8jnp (ro)
   Type              Status
   Initialized       True
   Ready             True
   ContainersReady   True
   PodScheduled      True
     Type:        Secret (a volume populated by a Secret)
     SecretName:  default-token-x8jnp
     Optional:    false
 QoS Class:       BestEffort
 Tolerations: for 300s
         for 300s
   Type    Reason     Age    From               Message
   ----    ------     ----   ----               -------
   Normal  Scheduled  7m40s  default-scheduler  Successfully assigned default/wordpress-blog to worker
   Normal  Pulling    7m40s  kubelet, worker    pulling image "wordpress:5.2"
   Normal  Pulled     7m38s  kubelet, worker    Successfully pulled image "wordpress:5.2"
   Normal  Created    7m38s  kubelet, worker    Created container
   Normal  Started    7m38s  kubelet, worker    Started container

Using the describe command against your pods is useful for troubleshooting problems. The Events section, found at the bottom of the output, provides a window into the activities performed to run the containers within the pod, and if there are any errors during container execution they will be outputted here.

Updating a Pod

It is very unlikely that your pod’s state will be static during its entire lifespan. You will likely need to update it at some point, such as to update WordPress version.

To update a pod you will first update the wordpress-blog.yml file used to create the pod. Then you apply the new configuration using kubectl apply.

kubectl apply -f wordpress-blog.yml

Creating a WordPress Pod Deployment

Kubernetes deployments are used to set a desired deployment state for your pods. You can set the number of replicas you want of your pod to run, for example.

Creating a WordPress Service

Pods are ephemeral by design, so they would not be good candidates for exposing to other services or to the public Internet. Instead, when we want to expose our applications running within a pod we must create a service definition.

Service definitions set how a service will be exposed on the network. There are several options to choose from, and the one you select will be for the particular use case of your service.

The load balancer service type will assign a public, routable IP address to your service. The load balancer provisioned will be determined by your Kubernetes network settings. If your cluster is running in GKE or Digital Ocean, for example, a compute load balancer will be provisioned.

Node level service types will expose your service using a port local a node. To access the service the IP address of the Kubernetes node the pods are running on will be used.

A cluster service type will expose the service to entire Kubernetes cluster. This type is useful for exposing internal services to other services and pods. For instance, if you were running a database service within your cluster it would unlikely need to be exposed to the Internet. Instead we can limit the expose to only resources running within our cluster.

Creating a Service

Create new filed called wordpress-blog-service.yml, and add the following contents to the file.

apiVersion: v1
kind: Service
  name: wordpress-blog-service
  type: LoadBalancer
    application: wordpress-blog
  - port: 80
  - port: 80 

To attach the service definition to your application a selector is used. The value specified in the selector’s application key is the name key value from your pod or deployment yaml file.

Create the service using the kubectl apply command.

kubectl apply -f wordpress-blog-service.yml