We have created WordPress application on Docker Compose
and on bootstrapped Kubernetes cluster.
Let's try it with GKE right now. But we are done
with writing YAML files, we have written a lot of
them. So this time, we will use Kubernetes engine
samples provided by Google. And we'll directly
clone them from GitHub. Use git clone, followed by this link.
There we go, let's see if the repository is here.
Well, it is. kubernetes-engine-samples
directory is quite huge. So let's take
k8s-samples out of it. Let's go to
k8s-samples directory. Let's list out the
components here and there are a lot of examples.
But we want to focus on wordpress-persistent-disks example.
Let's navigate to wordpress-persistent-disks directory,
and when we look into it,
we have a bunch of YAML files.
A few of them seem quite friendly, mysql.yaml, mysql-service,
wordpress.yaml, and wordpress-service.yaml.
These are all the files which we
have operated on previously. But we have a few new
files as well, which are mysql-volumeclaim and
wordpress-volumeclaim.yaml. What are those?
Let's check them out.
So it turns out that mysql-volumeclaim.yaml
is a file for declaring
a PersistentVolumeClaim. Persistent Volumes are
storage objects in Kubernetes. And since they are
persistent, even if the pod dies, the volume
doesn't vanish. So there needs to be a mechanism
through which the new born pod can mount itself
with the volume. So just like sources with
projected volume, Persistent Volumes have PVC or
PersistentVolumeClaims. These objects are used
by pods to claim a certain volume and use it
afterwards. Starting from the top, our kind is
PersistentVolumeClaim, which is using the same
apiVersion as pod or ReplicaSet, which is v1.
In the metadata section, we have given it its name.
To understand PersistentVolumeClaims better,
compare them with pods, they're actually pretty
similar to pods. Pods consume Node resources,
whereas PersistentVolumeClaims consume
Persistent Volume resources. Pod asks for CPU and
memory, whereas PersistentVolumeClaims ask for storage.
In spec section, we have two fields,
accessModes and resources. For different
applications, PersistentVolumeClaims have
different access mode, like ReadWriteOnces or ReadOnlyMany,etc.
Finally, it is going to ask for a
block of 200 gigabyte storage. Similarly, you can
also look at wordpress-volume-claim. Apart from
the name of the claim, nothing is different. So in
total, we're asking for 400 gigs of storage.
Let's apply both of these YAML files and create
PersistentVolumeClaims. You might be wondering
if PersistentVolumeClaims are a way to claim
storage from GCP, who actually provides this storage?
Well, if you remember a couple of demos
ago, when we looked at the storage section of our GKE
cluster, we found a storage class named standard.
Storage class is responsible for provisioning
storage to PersistentVolumeClaims.
[No Audio]
Now, let's create a secret for our mysql-password.
Next up, let's take a look at our deployments and services.
Let's start with mysql deployment.
It is quite like what we had used previously.
Apart from the fact that this time, it is not using an empty
directory as a volume, but it is using a
Persistent Volume. In Volumes field, we have the
name of the volume which is mysql-persistent-storage,
which means we are asking Kubernetes to
create this volume called mysql-persistent-storage
and our next lines will determine that this volume
is going to be a Persistent Volume. Reason is, just
like sources with projected volumes, we are
providing PersistentVolumeClaims with this
volume followed by the claim name which is mysql-volume-claim
or mountPath is also same as
what it was when we previously deployed wordpress.
Let's exit this file and create this deployment.
Next up, we have mysql-service of ClusterIP type.
It is exactly like what we had used previously, so we
can take a quick look at it and exit this file.
Let's quickly create the service as well and
check out our wordpress deployment, just like mysql-deployment.
Here too, the only difference is the
type of the volume, where we have provided
persistentVolume and you also mentioned the
claim, let's create this deployment as well.
Let's check out our wordpress-service, which is also
same as last time. But this time, we hope that its
type being LoadBalancer makes a significant impact.
Let's create the service and let's get a
list of services. Till now everything was going
just like how it went with our bootstrap
Kubernetes. But from this step onwards, we can see
the power of hosted or managed Kubernetes of GKE,
or LoadBalancer service is working perfectly
and we have an external IP 35.228.119.91
dedicated to our WordPress application, which
means that we don't have to reveal the external
IPs of the nodes. And even if we host a few more
applications on different ports, they will have
their individual IPS so we will have no IP
conflicts whatsoever. Furthermore, when you
describe the service wordpress, take a look at the events.
GKE is constantly making sure that the
LoadBalancer is working properly. Now let's go to
a new tab on our web browser and simply put the
external IP or the LoadBalancer IP of our
application. No curl, no combination of IP and
port number nothing, just a simple IP.
And there we go, our wordpress is up and running.