Part 1





In this 2 part tutorial, we will deploy real-world applications on a Kubernetes cluster. We will continue to use AWS as our cloud provider and continue to integrate AWS services with the Kubernetes cluster.

In this tutorial, we will use the following AWS services EC2 instances and EFS.

In our previous blogs (Kubernetes on CentOS-7 and Kubernetes on Ubuntu), we created Kubernetes clusters on CentOS-7 and Ubuntu 18.04 operating systems. It doesn’t matter which underlying OS you use, the Kubernetes commands and deployment are the same. You can choose CentOS-7 or Ubuntu 18.04, whichever is convenient for you.

For this tutorial, we will use the Kubernetes cluster created on CentOS-7.


What are real-world applications?


Any application that is containerized can be deployed on a Kubernetes cluster. In this tutorial, we will deploy a WordPress application.

WordPress is the most commonly used CMS (Content Management System) for creating websites. Since it is easy to create and manage a WordPress website, almost 64% of all websites on the internet use WordPress.


What is WordPress?


WordPress (WP or is a free and open-source content management system (CMS) written in hypertext preprocessor (PHP) language and paired with a MySQL or MariaDB database with supported HTTPS. Features include a plugin architecture and a template system, referred to within WordPress as “Themes”.


How to deploy a WordPress application on a Kubernetes Cluster?


Any docker container, called a “pod” in the Kubernetes world, can be deployed on a Kubernetes cluster using various Kubernetes tools like “kubectl”, “kops”, “helm”, etc. A “pod” can be deployed on a Kubernetes cluster using the command line. However, deploying a single pod is suitable for basic testing and validating a Kubernetes cluster, but is not very useful when deploying multiple pods.

To deploy Kubernetes pods we create “yaml” files. YAML is a human-friendly language. YAML files are mainly used for the configuration of pods, services and deployments. YAML is a manifest file, which performs the above-mentioned functions. They define how a “pod” should be deployed, and interact with other pods and/or services.

“Pods” communication is managed by Kubernetes services. Service is an abstraction to help you expose groups of Pods over a network. Each Service object defines a logical set of endpoints (usually these endpoints are Pods) along with a policy about how to make those pods accessible. For more details on services, please refer to the below link:




Step 1: Pre-requisites and Infrastructure setup



Use the CentOS-7 Master and Worker nodes AMIs created in this article.

Launch the 2 AMIs using EC2 instance =  “t3a.small” 2 vCPUs and 2 GB RAM for each EC2 instance.


Create 2 EFS storages. The first one is for storing the Kubernetes configuration files and the second one is for storing the WordPress data files.

Give appropriate names to the EFS storages (Ex: “config-files” for Kubernetes config files and “data-files” for the Kubernetes deployment data)


Creating AWS EFS and mounting it on an EC2 instance has been defined in this article.


Note: You can use even 1 storage and then create 2 separate mount points (1 for storing the Kubernetes configuration files and 1 for storing the WordPress data files). However, it’s always good practice to create 2 separate EFS mount points and then mount them on different directories.

Kubernetes “pods” are ephemeral, which means when the pod is stopped or killed all the data is lost. This is OK in a development environment but is not useful for production systems. In all our Kubernetes deployments, we will use Persistent Volumes.

Once the instances are launched, you have log in to the instances (Master and Worker) as the “jenkins” user. This user was created in the blogs mentioned here (Pre-requisites), and (CentOS-7 installation). It is important to follow the steps mentioned in these blogs on creating the correct user and setting up the systems before proceeding.

All the Kubernetes deployments are done from the Master node, but the pods are actually deployed on the worker nodes. For any Kubernetes deployment, you should take care to ensure that no pods should be deployed on the master node. Only the pods that are required to run the Kubernetes cluster should run on the Master node. All other application deployments should be on the Worker nodes ONLY.



How does Kubernetes deploy a WordPress application?


In our Kubernetes WordPress deployment when we use the Persistent Volumes (PV), the WordPress data is stored in the AWS EFS, which is mounted on a directory in the EC2 instance. Kubernetes pods do not directly access the PV, but it is done through Persistent Volume Claim (PVC). You can read more about PV vs PVC in the below link.,for%20storage%20by%20a%20user.

When we deploy a WordPress application, it deploys a WordPress pod and a MySQL pod. The WordPress pod is the front end in which we can log in, and make modifications to the website and which will finally show the website and its contents. The MySQL pod is the backend database which stores all the information and meta-data of the WordPress website.

We can control the number of WordPress pods that will be deployed. If we use multiple worker nodes then it is a good practice to deploy a WordPress pod on each of the nodes, so that there is High Availability in case of failure of an AWS availability zone.

However, you should not deploy multiple replicas of MySQL as this will cause data inconsistency. So you should ONLY deploy 1 replica of a database. In most cases where a database is used, Kubernetes recommends the deployment type

We will be using a separate deployment file for WordPress and MySQL. You can create a single deployment file for both, but it is easier to separate them.

In Kubernetes, pods communicate with each other using services. So each pod must have its own unique service defined. In our WordPress deployment, we will be using the Kubernetes service of the type: “NodePort

To make things easier, we have created 4 “yaml” files for each deployment (WordPress & MySQL). So there are 4 “yaml” files for WordPress (pv, pvc, deployment and service file) and 4 “yaml” files for MySQL (pv, pvc, deployment and service file).

What does a “yaml” file contain:

  • PV file –> For creating the Persistent Volume.
  • PVC file –> For providing the storage to the pods. 
  • Deployment file –> Specifies details about the number of pods, container image, volume mount points (PVC), etc.
  • Service file –> Specifies the port number of the service and type of service. 

In addition to the above 8 files (4 for WordPress and 4 for MySQL), there is a secret file which contains the MYSQL_DATABASE_PASSWORD. This a MySQL environment variable which needs to be specified in order for WordPress front to connect to the MySQL database. We will configure the WordPress config file to use this password.

Important: The secret file information is stored in a key:value pair format. The value of the key “password” in this file has the value in the base64 format. So if you change the database password, then this value in base64 should also be updated, or else you will get a database connection error.

So finally we have a total of 9 “yaml” files which we need to deploy to get WordPress up and running,


It may sound a bit confusing but we have configured the files in such a way, that you don’t really need to make too many changes and using these “yaml” files, you should be able to successfully deploy a WordPress application on your Kubernetes cluster.


Now that we have all the information, we are ready to deploy our WordPress application.


Part 2 –> Deploy the WordPress Application