WordPress in Kubernetes: The Perfect Setup

This tutorial shows how to prepare and deploy WordPress with all required dependencies (MySQL, etc) in Kubernetes.

Why WordPress? WordPress is usually chosen as the de facto application when explaining how to handle a process with a server software stack.

One of the challenges Kubernetes users face is deploying and re-deploying the same components required by their applications: databases like MySQL or MariaDB, MongoDB, Redis, Memcached, Elasticsearch; frontend servers like Nginx; or just a load balancer with HAproxy, to name a few examples.

If you have a CI/CD workflow in place, you probably have Jenkins or any other similar software deploying to Kubernetes via kubectl: Services, Deployments, ConfigMaps, Ingress controller and maybe even persistent storage. But if you are looking for something easier and more simple, there is a Kubernetes package manager that can help you: Helm.

Helm package manager and Kubernetes Charts

Helm is a Kubernetes package manager that allows you to package an application and handle all the required dependencies, including other services, and the configuration. The packages are called Charts. The idea is that instead of running kubectl to create the different deployments, services, etc. all the resources are defined in manifest templates that Helm installs as an atomic operation. Think of dpkg or yum, cpan or pip, but for Kubernetes apps.

Kubernetes Charts is the official repository that offers a central reference location for already packaged applications; at this time 60 apps are available in the stable branch.

Installing Helm in OSX or Linux

As a prerequisite, you will need kubectl authenticated and working against your Kubernetes instance in your cloud provider or you can use Minikube for testing in your local laptop.

On OSX, we recommend using Homebrew to install Helm:

% brew install kubernetes-helm

On Linux, you can download the latest release and unpack it:

% wget https://kubernetes-helm.storage.googleapis.com/helm-v2.2.0-linux-amd64.tar.gz
% tar xvzf helm-v2.2.0-linux-amd64.tar.gz
% sudo mv linux-amd64/helm /usr/local/bin/helm
Code language: JavaScript (javascript)

Init Helm in your Kubernetes cluster

Before moving along, Helm needs to be installed in your Kubernetes cluster as well. This is a very straightforward process and you just need to init Helm:

% helm init
$HELM_HOME has been configured at /home/bencer/.helm.


Tiller (the helm server side component) has been installed into your Kubernetes Cluster.
Happy Helming!
Code language: PHP (php)

This will create a containerized service in Kubernetes known as Tiller. From this point on, the Helm package manager installed in your laptop will communicate with Tiller running in Kubernetes via gRPC, and Tiller will be in charge of deploying, upgrading and deleting the apps in your cluster:

% kubectl get pods --all-namespaces
NAMESPACE     NAME                             READY     STATUS    RESTARTS   AGE
kube-system   kube-addon-manager-minikube      1/1       Running   0          3m
kube-system   kube-dns-v20-qzkhp               3/3       Running   0          2m
kube-system   kubernetes-dashboard-mtrl3       1/1       Running   0          2m
kube-system   tiller-deploy-2923173008-n21pw   1/1       Running   0          18s
Code language: JavaScript (javascript)

If you want to update the Chats database, like apt update, simply:

% helm repo update

And if you want to upgrade Tiller:

% helm init --upgrade

WordPress Deployment in Kubernetes

With Helm configured and Tiller up and running you can start deploying your favorite apps. For instance, let's search for WordPress Charts:

% helm search wordpress
NAME                VERSION DESCRIPTION                                       
stable/wordpress    0.4.2   Web publishing platform for building blogs and ...

And you can get more information about this Chart in a similar fashion to apt-cache:

% helm inspect stable/wordpress
description: Web publishing platform for building blogs and websites.
engine: gotpl
home: http://www.wordpress.com/
icon: https://bitnami.com/assets/stacks/wordpress/img/wordpress-stack-220x234.png
keywords:
- wordpress
- cms
- blog
- http
- web
- application
- php
maintainers:
- email: containers@bitnami.com
  name: Bitnami
name: wordpress
sources:
- https://github.com/bitnami/bitnami-docker-wordpress
version: 0.4.2

---
## Bitnami WordPress image version
## ref: https://hub.docker.com/r/bitnami/wordpress/tags/
##
image: bitnami/wordpress:4.7-r0
[...]
Code language: PHP (php)

Since we want our WordPress running in its own namespace, let's create one as we install the application:

% helm install --namespace wordpress --name wordpress stable/wordpress                                   

NAME:   wordpress
LAST DEPLOYED: Mon Mar  6 17:38:30 2017
NAMESPACE: wordpress
STATUS: DEPLOYED

RESOURCES:
==> v1/Service
NAME                 CLUSTER-IP      EXTERNAL-IP  PORT(S)                     AGE
wordpress-wordpress  10.109.108.55   pending>    80:32435/TCP,443:30044/TCP  2s
wordpress-mariadb    10.102.199.160  none>       3306/TCP                    1s

==> extensions/v1beta1/Deployment
NAME                 DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
wordpress-mariadb    1        1        1           0          1s
wordpress-wordpress  1        1        1           0          1s

==> v1/Secret
NAME                 TYPE    DATA  AGE
wordpress-wordpress  Opaque  2     2s
wordpress-mariadb    Opaque  2     2s

==> v1/ConfigMap
NAME               DATA  AGE
wordpress-mariadb  1     2s

==> v1/PersistentVolumeClaim
NAME                           STATUS  VOLUME                                    CAPACITY  ACCESSMODES  AGE
wordpress-wordpress-apache     Bound   pvc-551b2739-028b-11e7-ad79-12182a6edca4  1Gi       RWO          2s
wordpress-wordpress-wordpress  Bound   pvc-551b9867-028b-11e7-ad79-12182a6edca4  8Gi       RWO          2s
wordpress-mariadb              Bound   pvc-551c0c25-028b-11e7-ad79-12182a6edca4  8Gi       RWO          2s


NOTES:
1. Get the WordPress URL:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace wordpress -w wordpress-wordpress'

  export SERVICE_IP=$(kubectl get svc --namespace wordpress     wordpress-wordpress -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
  echo http://$SERVICE_IP/admin

2. Login with the following credentials to see your blog

  echo Username: user
  echo Password: $(kubectl get secret --namespace wordpress wordpress-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
none>pending>
Code language: HTML, XML (xml)

You can find all the available configuration options here, and you can set these either using the command line --set or in a YAML file. Also, all Charts output some instructions on how to proceed after the package is installed. In this case, you should see how to get the WordPress Ingress controller URL with:

% kubectl get svc --namespace wordpress wordpress-wordpress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'

Note: using .status.loadBalancer.ingress[0].ip didn't work for me as expected an IP address and I had a hostname instead, but you can always inspect the wordpress service with kubectl to get full details:

% kubectl describe svc wordpress-wordpress --namespace wordpress        
Name:           wordpress-wordpress
Namespace:      wordpress
Labels:             app=wordpress-wordpress
            chart=wordpress-0.4.2
            heritage=Tiller
            release=wordpress
Selector:       app=wordpress-wordpress
Type:           LoadBalancer
IP:         10.109.108.55
LoadBalancer Ingress:   a55201964028b11e7ad7912182a6edca-1068550576.us-east-1.elb.amazonaws.com
Port:           http    80/TCP
NodePort:       http    32435/TCP
Endpoints:      192.168.224.67:80
Port:           https   443/TCP
NodePort:       https   30044/TCP
Endpoints:      192.168.224.67:443
Session Affinity:   None
Events:
  FirstSeen LastSeen    Count   From            SubObjectPath   Type        Reason          Message
  --------- --------    -----   ----            -------------   --------    ------          -------
  9m        9m      1   {service-controller }           Normal      CreatingLoadBalancer    Creating load balancer
  9m        9m      1   {service-controller }           Normal      CreatedLoadBalancer Created load balancer

So just head to: https://a55201964028b11e7ad7912182a6edca-1068550576.us-east-1.elb.amazonaws.com and you will be able to access your new WordPress blog.

You can also check the administrator user credentials that are stored in a Kubernetes secret:

% kubectl get secret --namespace wordpress wordpress-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode

And if you want to see this information at any point, you can use helm status wordpress to show it again.

Helm can install and handle multiple apps, and can list the different apps installed:

% helm ls
NAME        REVISION    UPDATED                     STATUS      CHART           NAMESPACE  
sysdig      1           Mon Mar  6 12:40:22 2017    DEPLOYED    sysdig-0.2.0    default    
wordpress   1           Mon Mar  6 12:48:11 2017    DEPLOYED    wordpress-0.4.2 wordpress
Code language: CSS (css)

And you can also delete them once you have finished with helm delete.

Monitoring WordPress in Kubernetes

Along with your app stack, monitoring with telemetry and performance metrics for troubleshooting, dashboards and alerts is a must. Sysdig Monitor is probably your best bet for doing all this with one tool in Kubernetes and in less than 5 minutes!

Sysdig Monitor agent has always been very easy to install, either running the plain Docker command or deploying it using a DaemonSet, but now Sysdig can also be deployed with Helm since it's available in the official Kubernetes Charts repository.

You just need to run the following command, including the AccessKey, which you will find in your Sysdig Monitor user account settings.

% helm install --namespace sysdig --set sysdig.AccessKey="YOUR-ACCESS-KEY",sysdig.AgentTags="cluster:kubernetes-dev" stable/sysdig
NAME:   needled-quoll
LAST DEPLOYED: Mon Mar  6 16:02:49 2017
NAMESPACE: sysdig
STATUS: DEPLOYED

RESOURCES:
==> v1/Secret
NAME                  TYPE    DATA  AGE
needled-quoll-sysdig  Opaque  2     1s

==> extensions/v1beta1/DaemonSet
NAME                  DESIRED  CURRENT  READY  NODE-SELECTOR  AGE
needled-quoll-sysdig  3        3        0      none>         1s

NOTES:
Sysdig Monitor agents are spinning up on each node in your cluster. After a few seconds, you should see your hosts appearing in the Explore tab:

    https://app.sysdigcloud.com/#/explore/overview/l:10

No further action should be required.
none>
Code language: HTML, XML (xml)

That's it.

Now you can list both Charts running:

% helm list                              
NAME            REVISION    UPDATED                     STATUS      CHART           NAMESPACE  
needled-quoll   1           Mon Mar  6 16:02:49 2017    DEPLOYED    sysdig-0.2.0    sysdig     
wordpress       1           Mon Mar  6 15:28:10 2017    DEPLOYED    wordpress-0.4.2 mywordpress
Code language: CSS (css)

To start monitoring your Kubernetes deployment, go to Sysdig Monitor and from there you can visualize your deployment topology, configure dashboards and set up alerts. Through the Explore tab you can browse your infrastructure. Not only can you see hosts and containers running on them, you can also group containers using Kubernetes logic: cluster > namespaces > deployments or services > pods and containers.

Thanks to Sysdig's ability to autodiscover the services running in your containers you will automatically get views of your WordPress containers, including application-layer metrics such as: HTTP requests and HTTP error count per second, average and max response time for each microservice, and also which are the top requested URLs or which are the slowest ones!

Recommended alerts for WordPress in Kubernetes

Monitoring any service running in Kubernetes is a little more tricky that monitoring the same service in a bare metal static infrastructure. Now you have to monitor not only the host and the services but also the containers and the orchestration platform. There is no rule that fits all scenarios, but we are going to throw out a few suggestions here of what should probably be in your alerts list.

Host-level alerts

Is any of your hosts down? If its a minion it's probably not too bad because Kubernetes will reschedule the containers somewhere else. If it's your master and you only have one you will probably want to know ASAP.

You might want to add some other host-level resource consumption alerts like disk usage over 80%, if you have been swapping for a few minutes and the load is way above normal. But remember, it's not worth waking you up if there isn't anything broken.

Kubernetes alerts

This is the new layer and basically you want to make sure the resources defined by Kubernetes are running. For our WordPress example, I'm pretty sure that everyone would like to know if there are no containers running for a given service, which should never happen!

kubernetes.replicaSet.replicas.running 

But also, you will want to know if the number of container running is lower that the number of replicas you wanted. This can be triggered with the following condition:

kubernetes.replicaSet.replicas.running 

This should be applied to both the wordpress and mysql service.

Just making sure the containers are alive is not enough; you need to make sure they are not being continuously restarted because the process running inside is crashing. This is known as CrashLoopBackOff, and you can receive an alert when this happens using the restart count metric or an alert on the event:

We will apply this alert across everything in your cluster, making it trigger for each pod that matches this condition: kubernetes.pod.restart.count > 4 over the last 2 minutes.

Service level alerts

You still need to make sure that your services are running: that the WordPress webserver is responding to HTTP requests properly and queries are going through the MySQL database. Defining alerts at this level depends heavily on your traffic patterns. If you have a regular, sustained number of visits it is easy to set a minimum threshold of HTTP requests or MySQL queries, but if your traffic is random these kind of alerts will trigger many false positives.

In general, alerting should be configured using your working metrics (those that are a clear indicator that your app is working), triggering notifications to show that something has stopped working. Still, in most cases, you should set up a few alerts based on infrastructure availability or resources that always need to be there. If you want to learn more about Kubernetes alerting, don't miss our Monitoring Kubernetes (part 2): Best practices for alerting on Kubernetes.

Next steps

We think Helm is great for quickly and easily deploying the services you need for running your app in Kubernetes. Now you can also deploy the Sysdig Monitor agent with Helm too. If you want to close the circle you can create your own Chart package for your app and host it in your private repository, with everything still handled by Helm.

If you are looking at an even more user-friendly way to expose Helm to your Kubernetes users, check out Monocular, a Helm UI that you can also self-host in your Kubernetes.