Kubernetes - Using Persistent Disks with WordPress and MySQL

Kubernetes
Using Persistent Disks with
WordPress and MySQL

What Kubernetes is ?
▹ Kubernetes is an open-source container cluster
manager
￭ originally developed by Google, donated to the
Cloud Native Computing Foundation
￭ schedules & deploys containers onto a cluster of
machines
⬝ e.g. ensure that a specified number of
instances of an application are running
￭ provides service discovery, distribution of
configuration & secrets, ...
￭ provides access to persistent storage
▹ Pod
￭ smallest deployable unit of compute
￭ consists of one or more containers that are
always co-located, co-scheduled & run in a
shared context
3

▹ It can be run anywhere
￭ on-premises
⬝ bare metal, OpenStack, ...
￭ public clouds
⬝ Google, Azure, AWS, ...
▹ Aim is to use Kubernetes as an abstraction layer
￭ migrate to containerised applications managed by
Kubernetes & use only the Kubernetes API
￭ can then run out-of-the-box on any Kubernetes cluster
▹ Avoid vendor lock-in as much as possible by not using any
vendor specific APIs or services
￭ except where Kubernetes provides an abstraction
⬝ e.g. storage, load balancers
Why Kubernetes ?

Background
▹ WordPress is a blogging tool which uses MySQL as its database to store the blog articles and the local
filesystem to store assets, such as pictures in a blog post, or extensions. This tutorial uses the
official MySQL and WordPress container images from Docker Hub.
▹ In general, a container’s root filesystem is not suitable to store persistent data. The containers we
run on GKE are typically disposable entities, and the cluster manager may delete, evict, or reschedule
any containers that become unavailable due to node failure or other causes. In such an occurrence,
all data saved to a container’s root filesystem is lost.
▹ Using persistent volumes backed by persistent disks lets we store data for WordPress and MySQL
applications outside the containers themselves. This way, even if the containers are deleted, their
data persists.
▹ Both MySQL and Wordpress require a PersistentVolume to store data. For this tutorial, we will use
the default storage class which dynamically creates persistent disks and create two
PersistentVolumeClaims - one for each Deployment.
▹ Next, we create two Deployments: one for MySQL and one for WordPress. Both Deployments run only
a single replica of each Pod.

Before we begin !
▹ Take the following steps to enable the Kubernetes Engine API:
1. Visit the Kubernetes Engine page in the Google Cloud Platform Console.
2. Create or select a project.
3. Wait for the API and related services to be enabled. This can take several minutes.
4. Make sure that billing is enabled for project.

gCloud
▹ gcloud is used to create and delete Kubernetes Engine
clusters. gcloud is included in the Google Cloud SDK.
▹ kubectl is used to manage Kubernetes, the cluster
orchestration system used by Kubernetes Engine. we can
install kubectl using gcloud:
• gcloud components install kubectl

We need some files !
▹ mysql.yaml: The MySQL deployment configuration file.
▹ mysql-service.yaml: The MySQL service configuration file.
▹ mysql-volumeclaim.yaml: The MySQL PersistentVolumeClaim
configuration file.
▹ wordpress.yaml: The WordPress deployment configuration file.
▹ wordpress-service.yaml: The WordPress service configuration file.
▹ wordpress-volumeclaim.yaml: The WordPress
PersistentVolumeClaim configuration file.

Step 1: Create a GKE cluster
 The first step is to create a GKE cluster to host wer WordPress and
MySQL application containers. The following command creates a cluster
named persistent-disk-tutorial with 3 nodes:
• gcloud container clusters create persistent-disk-tutorial --num-nodes=3

Step 2: Create wer PersistentVolumes and
PersistentVolumeClaims
 In order to create the storage required for MySQL and Wordpress the first step is to create
PersistentVolumeClaims. When a PersistentVolumeClaim is created, if there is no existing
PersistentVolume for it to bind to, a new PersistentVolume is dynamically provisioned
based on the StorageClass configuration.
 GKE has a default StorageClass installed that will allow we to dynamically provision
PersistentVolumes backed by persistent disks. When a StorageClass is not specified in the
PersistentVolumeClaim, the cluster's default StorageClass is used instead.
 we will use the mysql-volumeclaim.yaml and wordpress-volumeclaim.yaml files to create
the PersistentVolumeClaims required for the deployments. The mysql-volumeclaim.yaml
and the wordpress-volumeclaim.yaml files looks like:

Step 3: Set up MySQL
 Deploy MySQL
 First step to deploy MySQL is to create a Kubernetes Secret to store the
password for the database. To create a Secret named mysql, run the
following command (and replace YOUR-PASSWORD with a passphrase
of your choice):
• kubectl create secret generic mysql --from-literal=password=YOUR-PASSWORD

This manifest describes a Deployment with a single instance MySQL Pod which will
have the MYSQL-ROOT-PASSWORD environment variable whose value is set from the
secret created. The mysql container will use the PersistentVolumeClaim and mount
the persistent disk at /var/lib/mysql inside the container.
To deploy this manifest file, run:
• kubectl create -f mysql.yaml
Check to see if the Pod is running. It might take a few minutes for the Pod to transition
to Running status as attaching the persistent disk to the compute node takes a while:
• kubectl get pod -l app=mysql
 Create MySQL Services
The next step is to create a Service to expose the MySQL container and make it
accessible from the wordpress container you are going to create.
You will use the Service manifest defined in mysql-service.yaml, which looks like:

Step 4: Set up WordPress
 Deploy WordPress
 The next step is to deploy your WordPress container to the container cluster. You will use
the wordpress.yaml manifest file to deploy a single instance WordPress container.
 The wordpress.yaml looks like:

 DeployWordPress
 This manifest describes a Deployment with a single instance WordPress Pod. This
container reads the WORDPRESS-DB-PASSWORD environment variable from the database
password Secret you created earlier.
 This manifest also configures the WordPress container to communicate MySQL with the
host address mysql:3306. This value is set on the WORDPRESS-DB-HOST environment
variable. We can refer to the database as mysql, because of Kubernetes DNS allows Pods
to communicate a Service by its name.
 To deploy this manifest file, run:
• kubectlcreate -f wordpress.yaml
 Check to see if the Pod is running. It might take a few minutes for the Pod to transition to
Running status as attaching the persistent disk to the compute node takes a while:
• kubectlget pod -l app=wordpress
 ExposeWordPressService
 In the previous step, you have deployed a WordPress container which is not currently
accessible from outside your cluster as it does not have an external IP address
 To expose your WordPress application to traffic from the internet using a load balancer
(subject to billing), you need a Service with type:LoadBalancer.
 To deploy this manifest file, run:
• kubectlcreate -f wordpress-service.yaml
 Deploying this manifest will create a load balancer, which may take a few minutes. Run the
following command to find out the external IP address of your blog:
• kubectlget svc -l app=wordpress

Step 5: Visit your new
WordPress blog
 After finding out the IP address of your blog, point your browser to this IP address and
you will see the WordPress installation screen as follows:
 Once you complete the WordPress setup, point your browser to the IP address of the
WordPress app again to visit your blog. Everything is working as expected.

Step 6: Test data persistence
on failure
 With PersistentVolumes, your data lives outside the application container. When
your container becomes unavailable and gets rescheduled onto another compute
instance by Kubernetes, GKE will make the PersistentVolume available on the
instance that started running the Pod.
 kubectl get pods -o=wide
 Now, delete the mysql pod by running:
 kubectl delete pod -l app=mysql
 Once the mysql Pod is deleted, the Deployment controller will notice that the Pod is
missing and will recreate the Pod. It is likely that the new mysql Pod will start on a
different node than it was running before.
 Run the following command again to observe that the mysql Pod is scheduled onto a
different compute instance than before (if not, you can delete the Pod again until it is
running somewhere different).
 kubectl get pods -o=wide

Step 7: Updating application images
 It’s important to keep deployed software up to date. For example, vulnerabilities may
be reported in WordPress that require an update. To update the WordPress container
image, find the newest image version on Docker Hub and update the image: value in
the wordpress.yaml file. To apply the update, run:
 kubectl apply -f wordpress.yaml

THANKS!
Queries ?
Find Us :
18
/pratik.netsquare pratik.lttrbx http://pratikrathod.in/
/snackeyes54 vahidsumra VahidSnackeyes

Kubernetes - Using Persistent Disks with WordPress and MySQL

Recommended

More Related Content

What's hot (20)

Similar to Kubernetes - Using Persistent Disks with WordPress and MySQL (20)

Recently uploaded (20)

Kubernetes - Using Persistent Disks with WordPress and MySQL