Where do I start with Kubernetes on GKE?

Creating a Kubernetes Cluster

I chose Minikube to understand how the pods and containers worked on a single node. Once I understood the working of a single node cluster, I decided to look into Google Kubernetes Engine's multi-node Kubernetes cluster. I set up Google cloud project and installed the necessary SDKs, the Kubernetes client, and the command-line tools.

The simplest way to deploy the application is to use the command-line tools. I created a cluster using the "gcloud container clusters create" command. This command accepts a list of parameters to create a cluster. I deployed Nginx Docker image to the Kubernetes cluster. The snippet below shows kubectl commands to run the image, list the pods, expose the service, and list the services.

 gcloud container clusters create the-cluster --num-nodes 2 --machine-type n1-standard-2 --zone us-east1-b
 kubectl run the-cluster --image=nginx --port 80 --requests="cpu=200m"
 kubectl expose deployment/the-cluster --type="NodePort" --port 80
 kubectl get services

Another way of configuring the properties is to use YAML or JSON. Some benefits of using YAML include: configuring properties without limitation; allowing improved readability both for the user and the system; providing a good data structure; and the ability to store in the version-control system. One thing I had to be careful about was the compatibility of the resources used in the YAML with the Kubernetes release version. For example, the Ingress resource I used in the below YAML is not available in Kubernetes release prior to 1.1.The YAML below uses three key kinds of objects for deploying an application. They are Deployment, Services, and Ingress.

Here are some key terminologies to know before applying configuration using YAML:

• Replication Controller is responsible for creating, monitoring, replacing, and running a specified number of pods.
• ReplicaSet is responsible for running one or more pods. It is a replacement for Replication Controller.
• LoadBalancer is a type of service that allows connecting to the pods from outside of the cluster through the load balancer's public IP.
• The Deployment is an alternative to Replication Controller for deploying an application. It is supported by ReplicaSet which manages and replicates the pod as needed. The specification shows
  • Replicas - the number of pods to create during deployment
  • Image - the Docker image to be deployed
  • Template - the instructions to create Kubernetes pods
• The Service exposes the pods. It accepts connection on the port and routes each connection to the target port. The IP address of the service doesn't change as long as it is alive. The specification uses NodePort to expose the pods to clients by reserving a port.
• The Ingress is an alternative to LoadBalancer service. Ingress has a single IP address and maps different services to different paths of the same or different host. GKE Ingress Controller takes care of load balancing the services. In the snippet below, Ingress exposes the service by mapping my.sample.com to the sample service.

Instructions for Using YAML To Deploy Nginx

Step 1: Start with the clean slate by removing the existing cluster.

 gcloud container clusters delete the-cluster --zone us-east1-b

Step 2: Create nginx-sample YAML and save it to your local folder.

 apiVersion: apps/v1beta1
 kind: Deployment
 metadata:
 name: sample-deploy
 spec:
 replicas: 1
 template:
 metadata:
 name: sample
 labels:
 app: sample
 spec:
 containers:
 - image: nginx:latest
 name: sample-server
 ports:
 - containerPort: 80
 protocol: TCP
 resources:
 requests:
 memory: "4Gi"
 cpu: "200m"
 ---
 apiVersion: v1
 kind: Service
 metadata:
 name: sample-svc
 spec:
 type: NodePort
 selector:
 app: sample
 ports:
 - port: 80
 targetPort: 80
 ---
 apiVersion: extensions/v1beta1
 kind: Ingress
 metadata:
 name: sample-ing
 spec:
 rules:
 - host: my.sample.com
 http:
 paths:
 - path: /
 backend:
 serviceName: sample-svc
 servicePort: 80

Step 3: Create the cluster using the command below.

 gcloud container clusters create the-cluster --num-nodes 1 --machine-type n1-standard-2 --zone us-east1-b

Step 4: The nginx-sample.yaml file has the instructions to create deployment, service, and ingress. Apply the configuration by file name.

 kubectl apply -f nginx-sample.yaml

Step 5: Use 'get ingress' command to get the address.

 kubectl get ingress

 NAME HOSTS ADDRESS PORTS AGE
 sample-ing my.sample.com 35.241.0.213 80 1m

Step 6: Map the host name and IP address by adding it to the /etc/hosts file. Open the /etc/hosts file and copy the following in the file: 35.241.0.213 my.sample.com
Note that I used the IP address from Step 3.

Step 7: Open a browser and enter http://my.sample.com/ to see the Nginx welcome page.

Options for Creating a Stack

Some options I explored for creating a custom stack include Chef, Puppet, Ansible, and Terraform. Chef, Puppet, and Ansible are configuration management tools, while Terraform is an orchestration tool. Throughout my research I used Docker images to deploy the application in Kubernetes. Most of the configuration management requirements are managed by Docker. The Docker image has everything configured, so the only aspect I was concerned with was the orchestration piece. An orchestration tool will help in provisioning servers to run the application, so I choose Terraform.

Examples on Terraform usages can be found here. I'm also listing Terraform resources from the Terraform documentation to read before creating infrastructure here:

• Create a GKE cluster using "google_container_cluster"
• Create firewall access to and from the instances using "google_compute_firewall"
• Manage a node pool resource using "google_container_node_pool"
• Create a VPC using "google_compute_network" and create a subnet using "google_compute_subnetwork" resource
• Create DNS service resources "google_dns_managed_zone" and "google_dns_record_set"
• Create modules that reuse the resources

Design Decisions

I learned that I have to take a few things into consideration before designing the infrastructure. As a designer, here are some questions I had to answer:

• Are there benefits of deploying different applications to the same pod?
• Should pods be scheduled closer or further away?
• Should pods be scheduled to a specific node or not?
• Should pods be co-located in the same geographic region and/or availability zone?
• Should a pod mount a volume that references an external persistent disk?
• Should different services be mapped to different paths of the same host or different hosts?
• How to handle existing and new connections after a SIGTERM signal is received?
• How long should we wait to close inactive connections before shutting down completely?
• Smaller images work well with Kubernetes. What are the necessary tools that will help in troubleshooting issues when running an image in a container, and still keep the image small?

Kubernetes provides many features, and it is up to the designer to choose the right design. It addresses the challenges faced by applications deployed in the cloud. This open-source platform provides a great value to manage microservices and run them efficiently, but comes with a learning curve for both developers and operations.

Resources

• Kubernetes in Action by Marko Lukša
• Google Cloud Platform Documentation
• Kubernetes Documentation
• GitHub Project - Kubernetes using Terraform
• Ansible vs Terraform
• Chef and Puppet
• Why we use Terraform
• Terraform Documentation