Newb-ernetes: Getting started with Kubernetes

When I first got interested in container orchestration I found the amount of terms and functionality in Kubernetes a bit overwhelming. So hopefully this will be helpful to you!

This tutorial series is for people who may be familiar using docker and want to learn how to deploy and manage workloads on a Kubernetes cluster. We’ll start with working directly with Pods and build into more advanced topics. For running our cluster locally we’ll use Minikube which boots up a one node cluster in a VirtualBox VM.

Check out Part 2: Playing with Pods

Terminology and Concepts

tl;dr version:

Nodes are physical/virtual machines and they run pods.
Pods run 1 or more docker containers.
ReplicaSets define number of pods that are always up and available.
Deployments handle declarative management of ReplicaSets.
Jobs are one off tasks that run to completion.
Services expose pods, replicasets, deployments and statefulsets to the interwebs.

You can also checkout this kubernetes terminology cheatsheet if you want to get your hair blown back.

Setup

For this tutorial you’ll need to install the following:

Or if you are on a Mac, run the following and then pat yourself on the back.

brew update
brew cask install minikube docker virtualbox
brew install kubectl

Next check your versions. If the versions are lower than the ones below, hopefully this tutorial still works. If your versions are higher, then greetings to you time traveler.

minikube version # v0.19.1
kubectl version --client # 1.6.4
docker --version # 17.03.1-ce

If you want to set up autocomplete for kubectl add source <(kubectl completion bash) or source <(kubectl completion zsh) to your shell.

Getting Started

The first step is to start minikube which will download the appropriate VMs and start up your single node “cluster.”

minikube start
# You should see output similar to:
Starting local Kubernetes v1.6.4 cluster…
Starting VM…
Moving files into cluster…
Setting up certs…
Starting cluster components…
Connecting to cluster…
Setting up kubeconfig…
Kubectl is now configured to use the cluster.

Next is to make sure everything is up and running:

kubectl get nodes
# You should see output similar to:
NAME       STATUS    AGE       VERSION
minikube Ready 26m v1.6.4

If this were a real cluster you would see a longer list of nodes (instances).

One more thing to check:

kubectl get namespaces
# You should see output similar to:
NAME          STATUS    AGE
default Active 3m
kube-public Active 3m
kube-system Active 3m

At this point you may have two questions:

How did kubectl find my cluster?

kubectl uses a config file located at ~/.kube/config to keep track of clusters you have authenticated to. This makes the kubectl command contextual if you have multiple clusters.

You can see which context you are using by running kubectl config current-context which should hopefully say “minikube.” If it is not set to “minikube” run kubectl config use-context minikube`.

The config subcommand can also set contexts such as cluster, user, or namespace.

What is a namespace?

Let’s ask the kubectl command. It can explain most of the things.

kubectl explain namespaces
# You should see output similar to:
DESCRIPTION:
Namespace provides a scope for Names. Use of multiple namespaces is optional.
...

Well that was helpful. ¯\_(ツ)_/¯

Namespaces are useful as scopes for a team or a project. They can also be used for applying resource quotas and controlling access through roles.

The official documentation recommends to only use namespaces when you need them. I tend to start with them immediately because it doesn’t take much thought to think of one and I don’t end up needing to move stuff around later. Namespaces can intercommunicate with each other.

All of the examples in the following tutorials will use namespaces as it also aids in easy cleanup by destroying the whole namespace.

Check out Part 2: Playing with Pods