A Kubernetes Tale: Part II — Gotta Kubernetise ’em all
By: Sebastian Scotti
Tags: DevOps, Google Cloud Platform, Java, Kubernetes, Docker

I’ll try to make this as clear as possible because there are a few steps to follow that might seem a lot the first time. There are three big steps as listed below:

Throughout this article, I consider that you have a basic knowledge of how Kubernetes works and the different components that are involved. If you don’t know enough about it, some time ago I wrote an article where I describe it all. Feel free to check it out too 👇

Before starting

The code 👾

You can find all the code used throughout this article in this repository:

The costs 💸

To give you a rough idea, while writing this article, I “spent” £0.30, and I forgot to turn off the Nodes at night. I “spent” because as I’m also using GCP’s free trial, I didn’t really pay anymoney.

Setting up the environment

If you come from Part I, all you have is a Docker image in your local repository you can run with a simple command. But to run that same image in your Kubernetes cluster requires some extra configuration, more concretely:

A Kubernetes cluster — because, duh A Container Registry — a place to push your Docker images so they’re accessible from your cluster (unless you want your clusters to pull the images from your computer, which I don’t know what about you, but doesn’t sound like a good idea to me) A credit card — because knowledge is free, but the servers where you’ll run you code aren’t (don’t panic, you’ll still have for your Christmas presents)

Create the cluster

First, sign-up on GCP and follow the steps to start your free trial (if you choose AWS/Azure you’re on your own today, mate). No instructions for this part, you Google “gcp” and literally the first result that comes back is “GCP — Get started for free”. There you go, point number 3 already done. Easy, right?(something that requires your money always is).

In the Kubernetes Engine cluster creation page (enable the service API if necessary) you can tweak multiple aspects of the cluster configuration. If you don’t want to think just click the My first cluster quick configuration which seems quite quirky if you’re a bit lost with all the buttons and knobs. Now, if you want to work for like 3 mins, to keep costs down for the test I suggest you use this config:

Zonal cluster on us-central1 region— one of the cheapest regions where the VMs (Nodes) will be created. Within that region, pick whichever zone you like. This means you’ll have your cluster in only one zone from that region.

While choosing any region might be fine for an initial test, a production cluster might require that you deploy it in specific areas (i.e.: in Europe, after GDPR was introduced, companies are required to process their users data in datacenters located in the continent). Here you can find the full list of GCP regions and zones.

Stable release channel — v1.16.13 at the time of writing this article. This option here is entirely up to you: auto-upgrades could break your releases without your knowledge and you could realise at the worst time possible (been there, done that). The alternative option is to select a master static version and you’ll be responsible of doing the upgrade. Here you have the latest release notes.

release channel — v1.16.13 at the time of writing this article. This option here is entirely up to you: could break your releases without your knowledge and you could realise at the worst time possible (been there, done that). The alternative option is to select a master and you’ll be responsible of doing the upgrade. Here you have the latest release notes. Preemptible e2-small machine type — you get a fraction (25%) of 2 vCPUs and it might get bursts of up to 2 full vCPUs for short periods; also as they’re preemptible, they live up to 24hs and offer no availability guarantee. So using it for testing…good. Using it for production…bad.

machine type — you get a fraction (25%) of 2 vCPUs and it might get bursts of up to 2 full vCPUs for short periods; also as they’re preemptible, they live up to 24hs and offer no availability guarantee. So using it for testing…good. Using it for production…bad. Single NodePool with 1 node with a 10GB (minimum allowed) boot disk — you can resize the NodePool and add/remove nodes later.

Hit Create and you’re golden! Wait for a few minutes until it’s fully provisioned. In the meantime, there are some other things to do. Point number 2 done!

If you’re a terminal person, just run this:

Link your terminal with your GCP account

Optional, but recommended

There are three ways to communicate with Kubernetes API:

CLI

REST API or

GCP’s web console

Anyway, we’re going to use…yes, you guessed right, the CLI.

To do this, we first need to link our terminal with our GCP account. Download gcloud SDK and follow the instructions to set it up.

Just so you know, GCP also offers something called Cloud Shell, which gives you a shortcut to all your Cloud resources. If you feel like it, just go to the top menu bar and click on the terminal-like icon. I prefer my local terminal because it’s faster and it’s handy if I need to use files from my computer.

Connect to your brand new cluster

Once your cluster is created, you’ll have a Connect button that will open a pop-up with a command to link your terminal to it: copy and paste it in your terminal.

This is how your cluster should look like on the list.

Pro tip: when you have a long list of clusters, it’s good to create aliases for all of them, so you don’t need to go back and forth to this page again.

Once you run the command, you’ll see something like this, meaning that the connection was successful

Setting up a container registry access

Originally I started writing this part here but finally decided to write its own article. Follow this link below to find out all about it 👇

Creating the deployment

Everything in the previous sections was a one-off thing. Now, what follows, is a configuration that you’ll have to do each time you want to deploy a new application to your cluster.

The dotted lines are optional and will depend on the needs of the deployment

Pushing to the Container Registry

If you’re doing this for the first time, you will first require to authenticate Docker against GCR. Remember that we gave our cluster access to it to pull images? Well, in this case we need to do the same, using our User Account to push said images. Luckily, gcloud provides a helper to do this in no time, just by running:

If you try to push without running the command above first, you’ll get an error message like:

unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication

Once Docker is configured, you’ll need to tag and push your Docker image with a GCR URL. How? Like this:

One important point here: it’s quite obvious, but you need to use the same GCR region domain you set up the Image Pull Secret in the cluster. Otherwise, you’ll be able to push, but the cluster won’t be able to pull as it won’t have the credentials configured for that domain (in the example in Setting up the container registry, I used us.gcr.io ).

The first time you run this it’ll have to push all the layers so it’ll take longer, depending on your Internet connection, your location and the location of the GCR region you chose.