Kubernetes: A Primer

Contents

• 🌊 Rough Seas
• 🚢 The Helmsman
• 🏗 The Components
  • 🧠 Inside the Cluster + Control Plane
    • Cluster
    • etcd
    • kube-scheduler
  • 🤖 Inside the Nodes
    • Nodes
    • Kubelet
    • Pods
    • kube-proxy
  • 🚜 Deployments + Types
    • Deployments
    • StatefulSets
    • ReplicaSets
    • DaemonSets
  • 🌎 Exposing + Interacting
    • Services
    • Kubectl
    • Volumes
    • PersistentVolumes
• 🧙‍♂️ DevOps Magic ✨
• 🐤 Minikube + You
  • • To Install (w/ Brew 🍺 ):
    • To Install (w/ Chocolatey 🍫 ):
    • Start a cluster by running:
    • Access the Kubernetes dashboard running within the minikube cluster:
    • Once started, you can interact with your cluster using kubectl, just like any other Kubernetes cluster. For instance, starting a server:
    • Exposing a service as a NodePort
    • minikube makes it easy to open this exposed endpoint in your browser:
• 👨‍💻 Conclusion
• 🔗 Links

🌊 Rough Seas

In previous blogs (Docker & VSCode DevContainers) we’ve talked about the powerful computing unit known as the ‘Container’ and how it solves many of the app issues of the past and what it can do for you. It’s also a core component of getting closer to a DevOps state. But today I want to talk about what happens when you need to traverse the digital ocean with many “containers” on your ship.

The Journey: From Traditional Server, to VM, to Containers

When we start to introduce multiple containers that need to talk to each other, integrate, scale and orchestrate at the same time or scheduled times this becomes very difficult to do with the average docker run command or a single docker-compose file…

So what can we do to solve this? Let’s talk about Kubernetes.

🚢 The Helmsman

Kubernetes is an open source piece of software that assists with management + orchestration of containers and container systems across a cluster of servers/virtual machines. It was originally built by Google, who were in need of ways to scalably run their millions of containers on premise and in the cloud. Google has developed three different container orchestration systems to achieve this, with the most recent (and most popular) being the open-source system - Kubernetes. The word originates from the greek meaning “helmsman” or “pilot”.

The word Kubernetes originates from Greek and means helmsman or pilot.

As Google has said - “Kubernetes’ design goal is to make it easy to deploy and manage complex distributed systems, while still benefiting from the improved utilisation that containers enable.”

🏗 The Components

So then we are left asking - how does this all work? Let’s dive into some of these components.

🧠 Inside the Cluster + Control Plane

Cluster

A standard Kubernetes installation is known as a Cluster. Inside of the Cluster lives the Control Plane. The Control Plane is responsible for managing all occurrences in the cluster. The Control Plane is a daemon process that coordinates all activities in the cluster, like deployments, roll outs, auto scaling, and monitoring. The API server is a component of the Kubernetes Control Plane that exposes the Kubernetes API. The API server is the front end for the Kubernetes Control Plane.

etcd

Consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data.

kube-scheduler

Control plane component that watches for newly created Pods with no assigned node, and selects a node for them to run on.

Factors taken into account for scheduling decisions include: individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and deadlines.

🤖 Inside the Nodes

Nodes

The Cluster is then made of up a component called Nodes. A Node is server (like a VM or even physical hardware) that acts as a worker within the Kubernetes Cluster. Nodes also house a container runtime system like Docker (or Windows Containers or whatever container runtime you love most).

Kubelet

All of these Nodes contain a component named the Kubelet which is a process that communicates with the Control Plane using the Kubernetes API. The Kubelet is the process responsible for managing the node and communicating with the Control Plane instance. The Kubelet also examines and uses the PodSpec that defines the Life-cycling and Maintenance of Containers within the pods that it is assigned.

Pods

Nodes then in turn contain pods, which are the smallest unit of Kubernetes. A pod is an abstraction over a container. A pod can (and will) usually include many containers. There is also a hidden container in every pod known as a “pause” container that holds the network namespace that other containers in the pod use to talk to localhost. 

kube-proxy

kube-proxy is a network proxy that runs on each node in your cluster, implementing part of the Kubernetes Service concept. It maintains network rules on nodes. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster.

🚜 Deployments + Types

Deployments

A Deployment provides declarative updates for Pods and ReplicaSets.

You describe a desired state in a Deployment (what containers you want, what are their settings and how many), and the Deployment Controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.

StatefulSets

Like a Deployment, a StatefulSet manages Pods that are based on an identical container spec. Unlike a Deployment, a StatefulSet maintains a sticky identity for each of their Pods. These pods are created from the same spec, but are not interchangeable: each has a persistent identifier that it maintains across any rescheduling.

ReplicaSets

A ReplicaSet ensures that a specified number of pod replicas are running at any given time. However, a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other useful features. Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless you require custom update orchestration or don’t require updates at all.

This actually means that you may never need to manipulate ReplicaSet objects: use a Deployment instead

DaemonSets

A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created.

Some typical uses of a DaemonSet are:

• running a cluster storage daemon on every node

• running a logs collection daemon on every node

• running a node monitoring daemon on every node

🌎 Exposing + Interacting

Services

Services are network pointers to pods. Because pods are (usually stateless) and ephemeral, they have dynamic IPs that can be reassigned if the pod is restarted or recreated. This can be inconvenient if trying to connect a network component to a pod by IP address. Services help by placing a static IP address (and DNS name) in front of one or many pods.

Kubectl

Kubectl is the command line interface for executing commands against a Kubernetes cluster. Kubectl has an extensive list of available commands and options to manage Kubernetes.

Volumes

Volumes exist within Pods and is a form of storage that essentially lives and dies with the Pod. Volumes decouple the storage from the Container. It enables safe container restarts and sharing data between containers within a pod.

PersistentVolumes

PersistentVolumes decouple the storage from the Pod. Its lifecycle is independent. It enables safe pod restarts and sharing data between pods. These are used using PersistentVolumeClaims - containers/deployments can grab storage from PersistentVolumes using these claims without caring about the underlying method serving this storage.

🧙‍♂️ DevOps Magic ✨

Kubernetes helps fundamental DevOps processes by automating the deployment and scalability of one of the most precious app components - the container.

Kubernetes also give you the ability to build your entire infrastructure as code. Every part of your applications and tools can be made accessible to Kubernetes, including security, ports and databases. Likewise, you can also manage environment configurations as code. Rather than running a script every time you need to deploy a new environment, you can provide Kubernetes with a source repository containing config files. In GCP environments IaC tools like KRM can be used to even spin up infrastructure outside of GKE - tightly coupling your app and your infrastructure into a single language and orchestration pipeline.

Additionally, code can be managed using version control systems, just like your applications in development. This makes it easier for teams to define and modify infrastructure and configurations and allows them to push changes to Kubernetes to be handled automatically.

It can also be extremely useful in addressing your SRE concerns as Kubernetes’ rolling updates and automated rollback features enable you to deploy new releases with zero downtime. Rather than having to take down production environments and redeploy updated ones, you can use Kubernetes to shift traffic across your available services, updating one cluster at a time.

🐤 Minikube + You

“Well now I really want to try it out - but don’t I need a cluster of powerful servers to do this?”

Introducing Minikube!

Minikube lets you run a single node Kubernetes cluster on your local dev machine really simply and easily - giving you the same experience as a full Kubernetes cluster in the cloud and being able to test your code and deployments locally.

To Install (w/ Brew 🍺 ):

To Install (w/ Chocolatey 🍫 ):

(Note: You’ll need a form of container environment like Docker, containerd or Podman to use Minikube)

Start a cluster by running:

Access the Kubernetes dashboard running within the minikube cluster:

Once started, you can interact with your cluster using kubectl, just like any other Kubernetes cluster. For instance, starting a server:

Exposing a service as a NodePort

minikube makes it easy to open this exposed endpoint in your browser:

👨‍💻 Conclusion

Give it a try! No really - trust me - it’s that simple and will get you well on your way to container orchestration on any platform. You won’t regret it.

It helps us address our DevOps concerns by focusing in and solving many problems with a few key pillars of DevOps, namely automated deployment, rollout and scalability. But not only that - it cuts some of the overhead of management of containers and gives deeper monitoring insight into our applications giving us more leverage in an SRE world.

Kubernetes is universal and can be run on pretty much everything and anything making it the ideal way to orchestrate multiple containers in any environment across any system.

🔗 Links

https://queue.acm.org/detail.cfm?id=2898444

https://www.atlassian.com/continuous-delivery/microservices/kubernetes

https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

https://minikube.sigs.k8s.io/docs/handbook/controls/

https://kubernetes.io/docs/concepts/overview/components/