What is it?

Put simple, Google Kubernetes Engine (GKE) is a cluster based operations solution where 'operations' means running stuff (Ops). In the Cloud it replaces the hardware and infrastructure that your traditional operations department manages on a daily basis. If you're a developer at hearth you might get a grin on your face thinking that finally you can get rid of that annoying operations department always complaining about your delivery and never being on time with their own... and perhaps you're right, but GKE doesn't completely remove the need to understand different aspects of operations.

What it really does is of course to help you achieve DevOps. Ideally it makes Ops doable for Dev and brings the two groups closer to each other. Ideally...

Before we deploy something on GKE we should do two things.

Create a VPC

VPC stands for Virtual Private Cloud and you can think of it as your own private network. You can have multiple VPC:s in every Cloud project but they can't overlap in terms of subnets.

When creating a cluster, which we will do next, you can either specify an existing VPC or have Google Cloud automatically create one for you. In this demo we are going to create one and specify its network ranges because we want to control them.

Controlling your network range is important if you are going to integrate with other Cloud projects or for that matter On-premises services. Then you want to avoid accidentally obtaining a network range that collides with the other service. And it so happens that integrating with another Cloud project, using VPN, is part of this showcase later on.

You can create a VPC network either using the web based Cloud Console or directly through your terminal using Google Cloud SDK. Here we'll do it through the terminal like this:

If you haven't enabled the Compute API the SDK will prompt you to do so. Type 'y' to enable it.

gcloud compute networks create pingpong-site1-net \
  --subnet-mode=custom

That created the main network, now we create the subnet with some non-overlapping network ranges:

gcloud compute networks subnets create pingpong-site1-subnet \
  --network=pingpong-site1-net \
  --region=europe-west3 \
  --range=172.20.0.0/16 \
  --secondary-range=pods=172.21.128.0/17 \
  --secondary-range=services=172.21.0.0/17

NOTE! The address ranges are just taken out of the air, not necessarily an optimal choice in any way. In a real life scenario always consider what is optimal for you.

When completed you can go to the VPC network view in the web Cloud Console and you should see this when viewing your network:

Create a Cluster

The final step before we can actually start deploying things is to create a cluster. Since the pingpong-service does not require huge amounts of resources, and yet hasn't gained much importance to mankind, we can do with a small zone-based preemptive cluster.

Zone-based means that it lives in a specific zone of a region. Notice that we created our VPC in europe-west3. That is a region, a group of data centers in Germany, and each region consists of zones; - individual data centers. We're going to put our cluster in europe-west3-a which is physically in Frankfurt. The downside with that decision is that if the data center in Frankfurt for some reason gets wiped off the face of the earth our service is gone. The upside is that it is a cheaper solution!

By creating a region-based cluster we could spread our risks so that it wouldn't be enough for the alien invasion to wipe out Frankfurt. But we'd have to pay more because we'd use more resources. Generally when operating a "real solution" region based clusters is a must!

Preemptive means that we use Googles overcapacity, i.e. the hardware that's just standing there anyway. This may result in our service being migrated, as the resources that we have temporarily allocated gets allocated by some other customer willing to pay a decent amount of money for it. However Google is not going to put us out in the cold with a service bouncing up and down as long as we make sure that the service is configured so that it can be migrated without downtime. Fortunately the pingpong-service is fantastic at getting migrated without downtime!

To create a cluster you can use the web Cloud Console but in this showcase, again, we'll do it using the SDK:

gcloud beta container --project "pingpong-site1-gcp-demo" clusters create "pingpong-site1-cluster" \
  --zone "europe-west3-a" \
  --no-enable-basic-auth \
  --release-channel "regular" \
  --machine-type "n1-standard-1" \
  --image-type "COS" \
  --disk-type "pd-standard" \
  --disk-size "100" \
  --scopes "https://www.googleapis.com/auth/devstorage.read_only","https://www.googleapis.com/auth/logging.write","https://www.googleapis.com/auth/monitoring","https://www.googleapis.com/auth/servicecontrol","https://www.googleapis.com/auth/service.management.readonly","https://www.googleapis.com/auth/trace.append" \
  --num-nodes "1" \
  --enable-cloud-logging \
  --enable-cloud-monitoring \
  --enable-ip-alias \
  --network "projects/pingpong-site1-gcp-demo/global/networks/pingpong-site1-net" \
  --subnetwork "projects/pingpong-site1-gcp-demo/regions/europe-west3/subnetworks/pingpong-site1-subnet" \
  --cluster-secondary-range-name "pods" \
  --services-secondary-range-name "services" \
  --default-max-pods-per-node "110" \
  --addons HorizontalPodAutoscaling,HttpLoadBalancing \
  --enable-autoupgrade \
  --enable-autorepair \
  --enable-tpu

NOTE! You might want to adapt the gke-version specified here since GKE continues to upgrade while this showcase does not! Also machine architecture is a steadily improving chapter and so it might also become deprecated and require a change. You can of course also create a cluster by using the Cloud console, sometimes that's just easier.

Get connected to the cluster

Connect to the newly created cluster by typing the following in your terminal:

gcloud container clusters get-credentials pingpong-site1-cluster \
  --zone=europe-west3-a

Do a check for anything that's already running to get an idea of that there is actually something there:

kubectl get pods --all-namespaces

You should see something similar to this:

NAMESPACE     NAME                                                             READY   STATUS    RESTARTS   AGE
kube-system   event-exporter-v0.2.4-5f88c66fb7-49djl                           2/2     Running   0          6m20s
kube-system   fluentd-gcp-scaler-59b7b75cd7-mbf9z                              1/1     Running   0          6m9s
kube-system   fluentd-gcp-v3.2.0-wm5vz                                         2/2     Running   0          5m45s
kube-system   heapster-86949d4f9-j89kv                                         3/3     Running   0          6m20s
kube-system   ip-masq-agent-7ppgt                                              1/1     Running   0          6m6s
kube-system   kube-dns-79868f54c5-74tcx                                        4/4     Running   0          6m21s
kube-system   kube-dns-autoscaler-bb58c6784-sxl7n                              1/1     Running   0          5m59s
kube-system   kube-proxy-gke-pingpong-site1-clust-default-pool-29a2d765-t8k3   1/1     Running   0          6m6s
kube-system   metrics-server-v0.3.1-57c75779f-f25v9                            2/2     Running   0          5m55s
kube-system   prometheus-to-sd-frgjf                                           2/2     Running   0          6m5s

This is Kubernetes stuff that you and I understand nothing of. But it seems to work!

Enough talk, let's deploy something now.