Creating a Kubernetes cluster and deploying a WordPress container

This section will walk you through setting up Docker containers in the cloud using Google Compute VM instances. We will also see what you need to do to expose your pod to external traffic. Let's see how we can set up a Kubernetes cluster running on the GKE.

First, we need to set up some default configuration properties before we create our container cluster:

1. Set the default compute zone and the compute region as appropriate. 

gcloud config set compute/zone ZONE
gcloud config set compute/region REGION

1. Use the gcloud container clusters create command to create a cluster running the GKE. The name of our cluster is my-first-cluster and we want this cluster to have exactly one node. This will be set up in the default zone and the default region that we specified in our configuration, that is, us-central1-a:

gcloud container clusters create my-first-cluster --num-nodes 1 

1. The confirmation message on the command line that says we have one node in this cluster and its current status is running. You can use the gcloud compute instances list command to see the list of clusters and VM instances that you have running. Also, note that with just one command GKE provisioned a fully-functional Kubernetes cluster. This saves a lot of time and efforts of manually configuring and spinning-up k8s clusters.
2. Now that we have a cluster up and running, we will deploy WordPress to it. WordPress is simply a content management system used for applications like blogging. We will deploy a WordPress Docker container on our cluster. This WordPress Docker container is publicly available as an image and can be accessed using --image=tutum/wordpress.

1. Use the command-line equivalent for working with Kubernetes clusters: the kubectl command. We want this container with the WordPress application to run on port 80. This WordPress image contains everything needed to run this WordPress site, including a MySQL database:

kubectl run wordpress --image=tutum/wordpress --port=80

Having deployed this container to your cluster, what you have created on your cluster is a pod. A pod is basically one or more containers that go together as a group for some meaningful deployment. In this case, for our WordPress container, there is one container within this pod.

You can use the kubectl get pods command to see the status of the pods that you have running. We have one pod that starts with the term wordpress. There are zero out of one (0/1) pods running and its current status is ContainerCreating, as shown in the following screenshot:

It's not ready yet. You can run the command another couple of times to see how the status is updated. At some point, you should see the status as running and it will also show as one out of one (1/1). Your pod is now ready with your Docker container running successfully on it.

1. When you first create a pod, its default configuration only allows it to be visible to other machines within the cluster. We don't want just the internal machines to access this spot. We want it to be made available to external traffic. This can be done by exposing the pod as a service so that external traffic can access your WordPress site. kubectl expose pod is the command that is used for this. Specify the name of your container, which is wordpress-, followed by a string of numbers and letters. The name that you want to specify for your containers is wordpress and the type of service to set up is a load balancer:

kubectl expose pod wordpress-2644474461-qjr06 --name=wordpress --type=LoadBalancer  

This load balancer creates an external IP address that this port can use to expect traffic. This is what makes your WordPress site available to external users as a service. Kubectl expose creates a service, the forwarding rules for the load balancer, and the firewall rules that allow external traffic to be sent to the pod. While exposing the pod, we named a service wordpress and you can now use this name in order to check the services that we have available.

1. You can use the kubectl describe services command, followed by the service name, to see information about your WordPress service. At the very bottom here, beneath the title events, you can see the series of events that have occurred on this cluster. The very first thing that we did was to create a load balancer. Run the command to describe the services again until you notice a couple of changes. The load balancer has finished creation and it now has an ingress IP address that you can use to direct external traffic tools. This added a new event:

1. Let's use this LoadBalancer ingress IP address to view our WordPress site running on the Kubernetes cluster. You will see the starter page to set up your WordPress site. If you have created a site on WordPress before, this should be very familiar to you. Click on the Continue button and you can then walkthrough the steps of actually creating a WordPress site if you want to:

1. If you switch back to the compute engine VM instances page and click through the cluster, the single node Kubernetes will show some activity because we deployed a WordPress Docker image to it and launched a site. You can explore the additional settings and config values that are associated with this Kubernetes cluster.

In this section, we learned what containers are and how they differed from VM instances. We have examined the architecture of container clusters in the GCP, the basic building blocks such as pods, and the underlying concepts such as Kubernetes that power the GKE. We now know that we need to run an explicit kubectl command in order to expose our pods to our external traffic and set up a load balancer, where our external traffic can be directed.

You can look into official kubernetes documentation for further reference on kubectl command line and various methods of operating objects and cluster: https://kubernetes.io/docs/reference/kubectl/overview/