An Overview of Kubernetes¶

Context¶

You are already aware that Docker solves the age old problem, "it works on my computer"¹. It lets you run small, constrainted 'virtual' machines on a single computer. Enabling you have multiple services exist on a single machine.

Docker Compose is then a tool that allows you to 'orchestrate' loads of Docker container on a single machine. This is nominally seen in mms_ws2 where we use the docker-compose.yaml file to specify the different flavours of Docker image that we want. We can tweak the configuration of containers using compose, changing things like:

• Which ports are exposed
• Which files are mounted to the container
• What it should do when it crashes etc.

Kubernetes (normally abbreviated to k8s, or K8s) solves the problem, how do I orchestrate multiple containers across multiple machines. It was originally developed by Google, who needed some way to figure out how to send users of their services to the correct server that was closest to them. To do that in a fault tolerant, scalable way that wasn't defendant on some humans to manually set up each individual server.

The architecture of a K8s Cluster¶

At the most simple level, a Kubernetes cluster is composed of 2 nodes.

1. Control plane
2. Worker node

The relationship is many too many, i.e you can have multiple control planes, and as many worker nodes as you want. The most basic example has two.

Control Plane¶

As the name suggests, this node is responsible for controlling the cluster. It tells each worker what container they are supposed to be running. It polls each worker on the status of their containers. It manages the state of the cluster, ensuring that any issues can be resolved by rolling back to a previous healthy version. To this end, there are a couple of moving parts in the control plane that are worth knowing about. These are all 'services' that run constantly.

• kube-scheduler
• kube-apiserver
• etcd

The kube-scheduler is responsible for deciding what services should be run when and where. It is the main communicator between the control plane the worker nodes.

The kube-apiserver is responsible for providing an external REST endpoint so that engineers can interact with the cluster and ask it to do things like start up a new server, kill an existing service etc.

etcd is a database that is used to store the state of the entire cluster. It takes snapshots of the states of all running containers and nodes and is used as a save point should the cluster need to heal or revert any changes.

Worker Node¶

Worker nodes are responsible for hosting the actual containers that the control plane tells them to. They run a single important service:

• kubelet

This kubelet service is what communicates with the control plane. Informing it about the state of the node, the containers running on it. The state of the containers running on it. It is also responsible for actually spinning up containers and executing instructions it receives from the control plane.

Kubernetes Jargon¶

There are a lot of technical terms that you have to know to read/understand any Kubernetes related content.

Cluster¶

This refers to a collection of nodes that work together to function as one entity.

Node¶

A node is a computer. That's it. It's just a computer. Whether it be your busted ass laptop, or a thousand dollar server.

Pod¶

A group of containers that come together to do a certain task, or exist as a tool. This is the smalled deployable compute object in Kubernetes.

Container¶

The same as a Docker container.

Objects¶

Kubernets follows a mental model where each 'thing' on a server is called an 'object'. You orchestrate these objects in order to achieve outcomes. There are different kinds of obejcts that you can choose from. Some common ones you'll see are:

• Workloads
  • Containers
  • Deployments
  • Jobs
  • Pods
• Services
  • Endpoints
  • Ingresses
• Config
  • Secrets
  • ConfigMaps
  • Volumes

Services¶

Since pods are ephemeral, you need some guaranteed way to always interact with them. Services are the resolver between user pings and getting it to the correct pod. An example is if you have a webserver that you are trying to accesss from outside the cluster. You could attempt to ping the IP address of the pod it's running on, but that pod could be killed/moved at any time by Kubernetes. In that instance, you would instead aim for the server that sits in front of the pods. It manages things like load-balancing, DNS resolution etc.

Further Reading¶

Kubernetes Overview Comprehensive Kubernetes Glossary