So far we talk about Docker and Docker Compose and have some hands-on configuration. Now we move to the very popular topic — Kubernetes. In Google Cloud, Kubernetes is the service that they pay much efford on it. But, what is Kubernetes? How it relates to Docker? Why should we use it? In this article, I will answer all these questions and have some hands-on configuration with WordPress. I choose WordPress as our hands-on configuration for two reasons. First of all, you could compare it with Docker Compose which is discussed in Part 2. Secondly, WordPress is a common application and we probably use it in our job. Now, let’s talk about what Kubernetes is.
What is Kubernetes?
Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications.
This sentence is cited from Kubernetes official web site. Let me explain more. Kubernetes is a container orchestrator which makes servers act like as one. Actually, it is nothing but just a set of APIs which run on top of Docker. We could use command line to manage containers across servers. In fact, Kubernetes is originally released by Goolge and now is maintained by open source community. That’s why I say Kubernetes is an important service in Google Cloud, or we could say this is also the selling point in Google Cloud. Nowadays, not only Google Cloud, AWS and other cloud providers also have their Kubernetes.
Why use Kubernetes?
As mentioned above, orchestration is a big reason to use Kubernetes. Of course, there are other orchestrators like Docker Swarm. But I would say, if you want to find a DevOps job, Kubernetes is more demanding. Then you may ask why orchestration is important. In Part 1 and Part 2, we discuss many about containers. However, if we change all servers into container, we should have a set of apprach to manage the containers. For example, we will care about the container lifecycle, scaling, failover, blue green deployment, networking, security and so on, just like we care about on traditional server.
How Kubernetes Works?
The whole architecture of Kubernetes is look like the above figure. It may be quite complicated for some of you are new to Kubernetes. But the concept is not so difficult. Imagine that you are the CEO, and you hire a manager called Kubernetes Master. And the manager is the supervisor of some staff called Kubernetes Node. When you want to implement something, you just tell the manager what you want without telling to the bottom staff. Your customers or users are just comminicating with the bottom staff only. Hope this analog could help you understand how Kubernetes work. As a matter of fact, we should know the below term in Kubernetes:
Kubernetes cluster: Kubernetes coordinates a highly available cluster of computers that are connected to work as a single unit
Master: Coordinates the cluster
Node: Single server in the Kubernetes cluster, as a worker to run applications
Kubectl: Command line to configure and manage Kubernetes
Pod: Pod is the basic execution unit of a Kubernetes application–the smallest and simplest unit in the Kubernetes object model that you create or deploy.
Controller: Create and update pods and other objects.
Volumes: A volume is just a directory, possibly with some data in it, which is accessible to the Containers in a Pod.
Service: Network endpoint which is used to connect to a pod. There are 3 popular types. Of couse, there are some other types like ingress. But we will not discuss here.
- ClusterIP — only work within cluser, internal IP is allocated.
- NodePort — port is usually high and open on every IP of node.
- LoadBalancer — only available if provider has Loadbalancer. It controls a loadbalancer endpoint external to the cluster.
Of course, there are many components I did not talk. But I think it is enough to have an overview of Kubernetes. You may have a brief concept about Kubernetes. Even though some of you may be still confused, now we will have some hands-on configuration instead of paper talk. Fortunately, it is very easy to use Kubernetes in GCP without installing additional software. In this article, I will demostrate all the things on GCP.
In general, a container’s root file system isn’t suitable to store persistent data. When nodes fail, all data saved to a container’s root file system is lost. Using PVs backed by Persistent Disk let us store our WordPress platform data outside the containers. In this way, even if the containers are deleted, the data persists.
There are 5 main steps we are going to do:
- Create a GKE cluster with name space
- Create a PV and a PVC backed by Persistent Disk
- Create WordPress and MySQL deployment and service
- Deploy the WordPress application
In console, we choose Cloud Shell and then click the editor mode such that we could easily review our code.
The we have to setup our environment e.g. define project, zone and region:
gcloud config set project <you-project-id>
gcloud config set compute/zone us-west1-a
gcloud config set compute/region us-west1
Please download my prepared file from github or
git clone https://github.com/manbobo2002/wordpress-k8s.git
I write a startup script to build up all the things automatically. However, I will still briefly go through the yaml file.
When we search Kubernetes Engine and click “Clusters”, we can see the cluster we created is shown here. Since we are using region=us-west1, machine-type=g1-small and num-nodes=1, there are total 3 instances with g1-small size, and each zone contains one node.
In the yaml file, we created two volumes with 10 GB for wordpress and mysql respectively.
All the storage we created can be found in this page.
In deployment yaml file, we focus on the “spec”, it states the planning for the application we want.
We define only 1 replica is required, the MySQL version is 5.6 with port 3306, the volumes is called mysql-volumeclaim which is created before.
Similarly, for WordPress we also define 1 replica, set the DB environment and attach the volume which is created before.
In “Workloads” page, we can see the status of the deployment.
All the secrets can be found in “Configuration”.
In service, we have to define the type of the service. For MySQL, we only want it works in internal cluster, so we choose ClusterIP, but for WordPress we want it to facing internet, so we choose LoadBalancer. Actually, we cloud also set port forwarding here, but we just keep the original i.e. the source port is the same as target port.
Similarly, we can check the status of service in “Services & Ingress” page.
Once all the yaml file is ready, we apply it to deploy.
Please note that on the “Services & Ingress” page, we can see the external IP of the WordPress application.
When we click on the endpoint, it will show the installation page here, that means WordPress is sucessfully deployed.
Testing Instance Failure
In “Details” tab, we scroll down and click “default-pool”.
Then we scroll down and see 3 instances are running. What happen if we delete one instance? Let’s try.
The instance is deleted. But we can see one of the instance groups is trying to add back one more instance.
Then if we wait for few minutes, the instance is re-created automatically. And the WordPress application resumes nomally.
Same as all my previous articles, I write a cleanup script for you to cleanup everything we create in this tutorial.
To sum up, Kubernetes is definitely the trending in DevOps. In future, Kubernetes will focus more on stability and security, also there are many new tools for operating and deploying Kubernetes like Helm. Helm is a Kubernetes package-manager that helps us manage Kubernetes applications. In addition, there are some new projects based on Kubernetes like Knative, K3S and K3OS. Thus, Kubernetes is worth to learn.