Kubernetes can be a daunting topic even to those well versed in docker. There are so many layers of abstraction on top of abstraction and new terms that it can seem like you need to learn a completely new dictionary just to understand the documenation. This series hopes to change that fact by assuming the only knowledge the reader has is of docker. We will assume that you know about:

  • Repositories (Both the hub and custom repositories)
  • Networking (How containers communicate on the same machine)
  • Images (How layers work and are stacked together)
  • Volumes (How to mount persistent data into a container)

If you are not sure on any of the above, I recommend doing a little more reading into those topics before coming back here to continue getting to grips with Kubernetes. Knowing the above will give you a good base to understand what’s going on and troubleshoot when things don’ quite go your way.

In this series, we will start off with practical explanations and lots of handwaving. There are lots of things in configuration files that you will see and not understand, that is fine and expected. The rule I have however, is that any term used in the process of an explanation or instruction must be previously explained in the series. As we proceed with the series we will begin digging into progressively deeper topics, but along the way you will always know what the terms mean.

To begin with, you should really get a cluster up and running to play with. Although the official documentation recommends minikube, I can’t get behind that unless you are really strapped for cash. Getting a fully fledged cluster up and running will give you a much better base upon which to build. I also do not recommend building your own cluster from scratch, as you will see in the coming sections there are many additional (and required for anywhere near a producion setup) items that require lots of effort to setup and which cloud providers have done for you. Instead, I recommend starting out with finding an affordabale managed kubernetes provider. My current choice for personal projects is Digital Ocean but feel free to go elsewhere, everything I cover will apply across platform unless otherwise specified.

There is no minimum specification required for your nodes, unless you have a good reason no to do so, I recommend getting the cheapest nodes you can. We’ve bumped into the first new piece of terminology - nodes. Nodes are the individual servers of your cluster, they could be VPS’s, hardware, or a mix of both. Kubernetes puts a lot of work into making individual nodes transparent to you unless you specifically ask for it not to be so. For now just know that a node is a normal server. I recommend you have at least two nodes in your cluster as this will be required for some demonstrations later on.

Once you’ve got your cluster setup and running to the point that running kubectl get nodes shows you at least two nodes and looks like:

# kubectl get nodes
NAME                  STATUS   ROLES    AGE    VERSION
pool-imttt1v83-b6n0   Ready    <none>   100m   v1.15.3
pool-imttt1v83-b6n1   Ready    <none>   100m   v1.15.3

you can move on to the next part where we will cover what a pod and a deployment is and get a simple hello world website running in our cluster.