Develop for Kubernetes and WordPress with Skaffold

In this article, I am going to show you, how to create a WordPress Kubernetes application using Skaffold and Kustomize so you can start developing for WordPress with Kubernetes, in your local environment straight away.

So What is Skaffold? And Kustomize?

If you don’t know Skaffold yet, Skaffold is a command-line tool developed by Google that makes it really easy to set up CI/CD for local, development and production environments with Kubernetes. It handles the full workflow of building and pushing docker containers to the docker container registry, and deploying applications to Kubernetes.

And what is Kustomize?

Kustomize is a tool in Kubernetes that makes it easy to bundle Kubernetes YAML files in order to deploy Kubernetes applications into distinct environments. 

For example, you can create a set of YAML files for local development, and another set of YAML files for the test environment, and another set of YAML files for a production environment, and so on. 

And you are probably wondering…. Do we really have to duplicate all the YAMLs for each new environment that we create?

The answer is no! Kustomize promotes configuration re-use by an inherit and patch strategy.

This approach is similar to Object-Oriented Programming, where you can define a parent class and then extend that parent class and then override what you need to change for that specific environment.

Skaffold and Kustomize go hand-in-hand

Yes, Skaffold can deploy a Kubernetes application with Helm or Kubectl without needing Kustomize. 

But for me using Kustomize as a deployer is a perfect marriage with Skaffold.

Let’s get started!

Installing Skaffold for Windows, Linux or MacOS

To install Skaffold, follow these instructions:

How to download source code for this tutorial

You can download the source code for this Skaffold tutorial from Github:

Creating Skaffold.yaml

To deploy WordPress with Skaffold you first need to create a skaffold.yaml in the root folder:

apiVersion: skaffold/v2beta12
kind: Config
- image: wordpress-example
context: .
dockerfile: Dockerfile_wordpress
- '**/*.php'
- '**/*.html'
- '**/*.js'
- overlays/local

Skaffold.yaml is the most important file for Skaffold. With this file we are telling Skaffold:

  • Where our docker files are
  • What file extensions we want to synchronize automatically after a change, without having to redeploy our Kubernetes application. This is the main power of Skaffold!
  • What deploy tool to use. You can choose one of Helm, Kustomize and Kubectl. In this case we select Kustomize
  • Where are the configurations YAML for Kustomize? Which folder to use for the default profile? This is typically the profile that we use for local development.
  • Other profiles that we might need. Typically used for CI/CD. This will be configured in the next article of our series when we plugin Skaffold to Gitlab CI. 

Creating the Dockerfile for WordPress

To run WordPress in Kubernetes we will use the official WordPress docker image available from the Docker hub with some minor additions like the all important wp-cli tool for WordPress. Also we want to replace whatever default website comes packaged with WordPress, with our own:



# install wordpress wp-client. It is rather useful
RUN curl -O
RUN chmod +x wp-cli.phar
RUN mv wp-cli.phar /usr/local/bin/wp

# replace wp-content with our own
RUN rm -fr /usr/src/wordpress/wp-content
COPY wp-content/ /usr/src/wordpress/wp-content/
RUN chown -R www-data:www-data /usr/src/wordpress/wp-content

WORKDIR /var/www/html

Creating the overlays and base folder

To store our Kubernetes YAML file, the Kustomize way, we create two folders in the root project:

  • base
  • overlays/local

All configuration that is common to all environments will be stored in base/ and each environment will have a folder created inside overlays/:

In our case for now we are only concerned about the local development environment, for now.

Each folder will have a kustomization.yaml file. The kustomization.yaml file contains the resources needed to deploy each layer of the configuration. By default Kustomize will look for this file in the folder. If the file does not exist, it will throw an error.

What goes inside kustomization.yaml

kind: Kustomization
- name: mysql-pass
- databaseName=wordpress
- username=wordpress-db-user
- password=aNotSoSecretPassword
- name: mysql-root-pass
- password=aNotSoSecretRootPassword
- wordpress-deployment.yaml
- mysql-deployment.yaml


kind: Kustomization

- wordpress-deployment-patch.yaml
- mysql-deployment-patch.yaml

- mysql-volumes.yaml

- ../../base

Inside kustomization.yaml, you can different types of generators like secretGenerator’s, configMapGenerator, and different attributes like resources, patches, bases, etc. More details on what goes inside are available here.

The rule of thumb is if you want to generate any secrets or config for your Kubernetes application, use the generators available to Kustomize.

For any Kubernetes yaml files to include in the configuration layer, use the resources section. This is only for new Kubernetes objects that have not yet been created in the parent layer. 

If you need to patch an existing Kubernetes object, use the patches attribute. 

The bases attribute is where we specify which configuration layers we inherit from. As the name suggests you can inherit configuration from more than one layer. This can be useful in more complicated environments.


First we define the service that is going to expose WordPress as a service in Kubernetes of type ClusterIP:

apiVersion: v1
kind: Service
name: wordpress-svc
app: cms
- port: 80
targetPort: 80
protocol: TCP
name: http
app: wordpress
tier: frontend
type: ClusterIP

What is a ClusterIP service in Kubernetes?

A Kubernetes service of type ClusterIP means that the service is only accessible from inside the Kubernetes cluster. This means that only container to container communication is possible. 

Why use service of type ClusterIP and not NodePort or LoadBalancer?

We want to expose the WordPress Service to the outside world using an Nginx Ingress when we deploy WordPress on GKE So in this case, a ClusterIP service is the most secure option we can use.

Labels and Selectors

You will have noticed that inside the service spec section, we have defined a selector:

app: wordpress
tier: frontend

Each object in Kubernetes can be assigned a label. A label is a key/value pair, which is intended to identify meaningful attributes of the object that it is attached to. These should be meaningful to us. But for Kubernetes itself, labels are simply used as search queries so that it knows how to make the right connections via selectors.

This selector will help Kubernetes to identify which pods the service will expose. In the YAML above, the selector will apply to any deployment with pods labeled with app=wordpress and tier=wordpress. 

The remainder of the configuration for WordPress should be self-explanatory.

Starting Skaffold

Now that all the configuration has been correctly created, let’s execute Skaffold:

First, we start our Kubernetes Cluster:

$ minikube start
😄 minikube v1.13.0 on Darwin 10.15.6
✨ Automatically selected the docker driver
🎉 minikube 1.18.1 is available! Download it:
💡 To disable this notice, run: 'minikube config set WantUpdateNotification false'
👍  Starting control plane node minikube in cluster minikube
🚜 Pulling base image ...
🔥  Creating docker container (CPUs=2, Memory=8100MB) ...
🐳 Preparing Kubernetes v1.19.0 on Docker 19.03.8 ...
🔎 Verifying Kubernetes components...
🌟 Enabled addons: default-storageclass, storage-provisioner
❗  /usr/local/bin/kubectl is version 1.16.6-beta.0, which may have incompatibilites with Kubernetes 1.19.0.
💡 Want kubectl v1.19.0? Try 'minikube kubectl -- get pods -A'
🏄 Done! kubectl is now configured to use "minikube" by default

And then we can run Skaffold:

$ skaffold dev
Listing files to watch...
- wordpress-example
WARN[0002] list of file paths deprecated: see
WARN[0002] list of file paths deprecated: see
Generating tags...
- wordpress-example -> wordpress-example:35120fe-dirty
Checking cache...
- wordpress-example: Not found. Building
Found [minikube] context, using local docker daemon.
Building [wordpress-example]...
WARN[0003] Skipping wp-content/uploads. Only relative symlinks are supported.
Sending build context to Docker daemon 7.123MB
Step 2/12 : FROM wordpress:$WORDPRESS_VERSION
5.6.2: Pulling from library/wordpress
45b42c59be33: Pulling fs layer
d39e54d371f3: Pull complete
Digest: sha256:73cfcbf1e511d760d9fc6c4864aeba1f8c856ba2be333a7d342fd76935055e9d
Status: Downloaded newer image for wordpress:5.6.2
---> bbd9ec4bf176
---> Running in 1da587342c7b
---> a1861a6fa1dc
---> Running in 88d7f0147a86
---> c864ceb69846
Step 5/12 : WORKDIR /tmp
---> Running in bacb1035d8aa
---> 39c6ee3c5456
Step 6/12 : RUN curl -O
---> Running in b6ba3b52cb79
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5437k 100 5437k 0 0 4125k 0 0:00:01 0:00:01 --:--:-- 4125k
---> 366a8437f773
Step 7/12 : RUN chmod +x wp-cli.phar
---> Running in 314e501f3a60
---> 2a501ae49d7f
Step 8/12 : RUN mv wp-cli.phar /usr/local/bin/wp
---> Running in 34b9ee8ec8af
---> 64b24df1a38f
Step 9/12 : RUN rm -fr /usr/src/wordpress/wp-content
---> Running in b8ccf3f07556
---> 8b8ccc879b79
Step 10/12 : COPY wp-content/ /usr/src/wordpress/wp-content/
---> 9e1ba82f5936
Step 11/12 : RUN chown -R www-data:www-data /usr/src/wordpress/wp-content
---> Running in f30f3e8ff65b
---> ca2edce5360c
Step 12/12 : WORKDIR /var/www/html
---> Running in 6156018a9377
---> e1a10f651d1c
Successfully built e1a10f651d1c
Successfully tagged wordpress-example:35120fe-dirty
Tags used in deployment:
- wordpress-example -> wordpress-example:e1a10f651d1c77dae1dd539cabcf76432484c3d41f9e0c3c7c65a4f10d7024ef
Starting deploy...
- secret/mysql-pass-fgtd4m85fh created
- secret/mysql-root-pass-62698g86tg created
- service/wordpress-mysql created
- service/wordpress-svc created
- deployment.apps/wordpress-mysql created
- deployment.apps/wordpress created
- persistentvolumeclaim/mysql-persistent-pvc created
Waiting for deployments to stabilize...
- deployment/wordpress is ready. [1/2 deployment(s) still pending]
- deployment/wordpress-mysql: creating container mysql
- pod/wordpress-mysql-77d8ddf54-8n6kq: creating container mysql
- deployment/wordpress-mysql is ready.
Deployments stabilized in 36.759 seconds
Press Ctrl+C to exit
[wordpress] WordPress not found in /var/www/html - copying now...
[wordpress] Complete! WordPress has been successfully copied to /var/www/html
[wordpress] AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using Set the 'ServerName' directive globally to suppress this message
[wordpress] AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using Set the 'ServerName' directive globally to suppress this message
[wordpress] [Wed Mar 31 15:18:51.473459 2021] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.38 (Debian) PHP/7.4.16 configured -- resuming normal operations
[wordpress] [Wed Mar 31 15:18:51.473592 2021] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
WARN[0081] list of file paths deprecated: see
WARN[0081] list of file paths deprecated: see
Watching for changes...
WARN[0082] list of file paths deprecated: see
WARN[0082] list of file paths deprecated: see

Our Kubernetes WordPress application was deployed correctly. You will see some SQL connection errors at startup, but that’s only because WordPress is trying to connect to the Mysql database, and the database initially is not available. By default in the local development environment, we deploy to the default namespace.

But let’s ensure that the WordPress and MySQL pods are running properly first:

$ kubectl get pods
wordpress-694954759d-85txs 1/1 Running 0 3m54s
wordpress-mysql-77d8ddf54-8n6kq 1/1 Running 0 3m54s


$ kubectl get deployment
wordpress 1/1 1 1 7m44s
wordpress-mysql 1/1 1 1 7m44s

To see what Kubernetes services we have available:

kubectl get svc                 
kubernetes ClusterIP <none> 443/TCP 10m
wordpress-mysql ClusterIP None <none> 3306/TCP 9m24s
wordpress-svc LoadBalancer <pending> 80:30737/TCP 9m24s

To access the wordpress home page, we need to create a tunnel for our WordPress service. 

minikube service wordpress-svc --url
🏃 Starting tunnel for service wordpress-svc.
| default | wordpress-svc | | |
❗ Because you are using a Docker driver on darwin, the terminal needs to be open to run it.

And Voila! We now can access the WordPress Install page.

After the install we finally see the WordPress Homepage:

As an exercise try to change locally some PHP file in the wp-content folder and see any changes appear immediately.

I do that test in my latest video. 

Hope you found this article useful. In my next article in this series, I am going to be extending Skaffold to deploy a Kubernetes application to Google Kubernetes Engine using Gitlab CI.

Until them, happy coding!