Friendly Introduction Of Kubernetes


What is Kubernetes?

Why is K8s so in demand? Kubernetes makes it easier for you to automatically scale your app, reduce downtime, and increase security. No more writing scripts to check, restart, and change the number of Docker containers. Instead, you tell K8s your desired number of containers and it does the work for you. K8s can even automatically scale your containers based on resources used.

K8s doesn’t make a lot of sense for a basic static website that gets a handful of visitors per day. Its use case is for larger apps that might have to scale up and down quickly.

Keeping the many K8s abstractions straight can be tricky. I’ll explain how the key parts fit together so you can wrap your head around this powerful platform. Let’s explore key K8s concepts and how they relate to each other.

First we’ll look at six layers of abstraction and the parts that make them up. Then we’ll look at seven other key K8s API objects.

Layers of K8s

Details Of K8s Layer

The levels shaded blue are higher-level K8s abstractions. The green levels represent Nodes and Node sub process that you should be aware of, but may not touch.

Note that your K8s instances will often have multiple Pods that can run on a single Node.

Deployment — If you want to make a stateless app that will run continuously, such as an HTTP server, you want a Deployment. Deployments allow you to update a running app without downtime. Deployments also specify a strategy to restart Pods when they die.

ReplicaSet — The Deployment creates a ReplicaSet that will ensure your app has the desired number of Pods. ReplicaSets will create and scale Pods based on the triggers you specify in your Deployment. Replication Controllers perform the same function as ReplicaSets, but Replication Controllers are old school. ReplicaSets are the smart way to manage replicated Pods.

Pod — a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers. Even if the pod has several containers, they will all be reachable in the network through a single IP address. Pods handle Volumes, Secrets, and configuration for containers. Pods are ephemeral. They are intended to be restarted automatically when they die. Pods live on Worker Nodes.

A K8s Cluster consists of a Cluster Master and Worker Nodes.

Worker Node — A Worker Node is also referred to as a Node for short. A Node is an abstraction for a machine — either a physical machine or a virtual machine. Think of a Node as a computer server. One or more Pods run on a single Worker Node. A Pod is never split between two Nodes — a Pod’s contents are always located and scheduled together on the same Node.

Cluster Master

Node Processes

Master Components

API Server — Exposes the K8s API. It’s the frontend for Kubernetes control. (aka. kube-apiserver) Think hub.
etcd — Distributed key-value store for Cluster state data. Think Cluster info.
Scheduler — Selects the Nodes for new Pods. Good guide here. (aka kube-scheduler) Think matcher.
kube-controller-manager — Process that runs controllers to handle Cluster background tasks. Think Cluster controller.
cloud-controller-manager Runs controllers that interact with cloud providers. Think cloud interface.

Worker Node Components

kubelet — Responsible for everything on the Worker Node. It communicates with the Master’s API server. Think brain for Worker Node.
kube-proxy — Routes connections to the correct Pods. Also performs load balancing across Pods for a Service. Think traffic cop.
Container Runtime — Downloads images and runs containers. For example, Docker is a Container Runtime. Think Docker.

Replica Sets, Stateful Sets, and Daemon Sets

Sometimes your app will need to keep information about its state. You can think of state as the current status of your user’s interaction with your app. So in a video game it’s all the unique aspects of the user’s character at a point in time.

Stateful Set — Like a Replica Set, a Stateful Set manages deployment and scaling of a group of Pods based on a container spec. Unlike a Deployment, a Stateful Set’s Pods are not interchangeable. Each Pod has a unique, persistent identifier that the controller maintains over any rescheduling. StatefulSets for good for persistent, stateful backends like databases. The state information for the Pod is held in a Volume associated with the StatefulSet. We’ll discuss Volumes in a bit.

Daemon SetDaemon Sets are for continuous process. They run one Pod per Node. Each new Node added to the cluster automatically gets a Pod started by the Daemon Set. Daemon Sets are useful for ongoing background tasks such as monitoring and log collection. StatefulSets and Daemon Sets are not controlled by a Deployment. Although they are at the same level of abstraction as a Replica Set, there is not a higher level of abstraction for them in the current API.

Now let’s look at Jobs and CronJobs

Job — A Job is a supervisor for Pods that run a batch process. A Job creates Pods and ensures they do a task by tracking the number of successful Pod completions. Unlike a ReplicaSet, once the process inside the container finishes successfully, the container is not restarted. Use a Job when you want to run a process once.

Cron Job — If you want to run a Job at regular, specified times (e.g. hourly, daily, or monthly), create a CronJob. A CronJob is similar to a Job, but is scheduled to repeat at regular intervals or set times. You’ll often need to create a Service to provide consistent access to your ephemeral Pods.


Volumes, Persistent Volumes, and Persistent Volume Claims

K8s Volume types include empty directories, Worker Node’s filesystems, and cloud provider-specific storage. For example, awsElasticBlockStore and gcePersistentDisk are provider-specific options for long-term storage.

Persistent Volumes & Persistent Volume Claims— To help abstract away infrastructure specifics, K8s developed PersistentVolumes and PersistentVolumeClaims. Unfortunately the names are a bit misleading, because vanilla Volumes can have persistent storage, as well. PersisententVolumes (PV) and PersisentVolumeClaims (PVC) add complexity compared to using Volumes alone. However, PVs are useful for managing storage resources for large projects.

With PVs, a K8s user still ends up using a Volume, but two steps are required first.

  1. A PersistentVolume is provisioned by a Cluster Administrator (or it’s provisioned dynamically).
  2. An individual Cluster user who needs storage for a Pod creates a PersistentVolumeClaim manifest. It specifies how much and what type of storage they need. K8s then finds and reserves the storage needed.

The user then creates a Pod with a Volume that uses the PVC. PersistentVolumes have lifecycles independent of any Pod. In fact, the Pod doesn’t even know about the PV, just the PVC. PVCs consume PV resources, analogously to how Pods consume Node resources.

Recap the topic

Let’s recap the K8s concepts we’ve seen. Here are the six levels of abstraction for a Deployment:

  • Deployment: manages ReplicaSets. Use for persistent, stateless apps (e.g. HTTP servers).
  • ReplicaSet: creates and manages Pods.
  • Pod: basic unit of K8s.
  • Node Cluster: Worker Nodes + Cluster Master.
    - Worker Nodes: machines for Pods.
    - Cluster Master: directs worker nodes.
  • Node Processes
    Master subcomponents:
    - API server: hub.
    - etcd: cluster info.
    - scheduler: matcher.
    - kube-controller-manager: cluster controller.
    - cloud-controller-manager: cloud interface.
    Worker Node subcomponents:
    - kubelet: Worker Node brain.
    - kube-proxy: traffic cop.
    - container-runtime: Docker.
  • Docker Container: where the app code lives.

7 additional high-level K8s API objects to know:

  • StatefulSet: Like a ReplicaSet for stateful processes. Think state.
  • DaemonSet: One automatic Pod per Node. Think monitor.
  • Job: Run a container to completion. Think batch.
  • CronJob: Repeated Job. Think time.
  • Service: Access point for Pods. Think access point.
  • Volume: Holds data. Think disk.
  • PersistentVolume, PersistentVolumeClaim: System for allocating storage. Think storage claim.

Full Stack Developer | Software Engineer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store