Workshop archive · Docker & Kubernetes · 24 slides

Kickstarting KubernetesFrom containers to a cluster

Why containers exist, how Docker images are built and shared, and how Kubernetes runs them — followed by hands-on sessions setting up a cluster and deploying to it.

By Nikhil Krishna · Paid workshop · Intern onboarding

An HTML edition of my original workshop slides, lightly copy-edited. I taught this as a paid workshop and also used it to onboard interns at UST Global’s Infinity Labs. The illustrations and technical content reflect the material at the time; this is a historical presentation. The two hands-on sessions were taught live at the keyboard and aren’t captured here.

Present slides Save as PDF

In the slides, press S for speaker notes, O for the overview and F for full screen.

Contents
Introduction01 / 24

Kickstarting Kubernetes

Nikhil Krishna
Paid workshop

Introduction02 / 24

Agenda

  • Introduction to containers and containerisation
  • An overview of Docker and how to use it

Tea break

  • Diving into container orchestration with Kubernetes

Lunch

  • Hands on Kubernetes — setting up a cluster
  • Hands on Kubernetes — deploying containers to your cluster
  • What next? Some avenues to explore
Why containers03 / 24

The “good old days”

  • One physical server — one application (often even more than one application)
  • Single stack — one language
  • More compute — purchase hardware
  • Servers were treated as pets and given names
  • Hardware was over-specified to account for “surge” scenarios, resulting in waste

It gets better…

  • Virtual machines add a layer of abstraction over the server so that
    • One physical server — multiple VMs — multiple stacks — multiple applications
  • More efficient, as server load could be adjusted and optimised
  • More compute — spin up another VM
  • Enabled cloud computing
Why containers04 / 24

IT has problems, and it looks like something from another industry

“The Matrix From Hell”: a grid with software stacks such as MySQL, Redis, Python and Cassandra down the side and hardware from laptops to cloud servers along the bottom, every cell a question mark.
Original workshop illustration · View full size
“Another Matrix From Hell”: the same grid for shipping, with goods from pianos to cars down the side and transport from trains to ships along the bottom, every cell a question mark.
Original workshop illustration · View full size
Why containers05 / 24

Maybe we can use the same concepts

“The intermodal shipping container”: a standard blue shipping container.
Original workshop illustration · View full size
“Containerization = operating system virtualization”: stacked shipping containers beside the list — lightweight, isolated, runnable, portable, a new way to package everything an app needs to run.
Original workshop illustration · View full size
Why containers06 / 24

VM architecture | container architecture

Side-by-side stacks. Hypervisor architecture: a server, a hypervisor, then a VM and a full OS beneath each app. Container architecture: a server and one operating system, with apps in thin containers directly on top.
Original workshop illustration · View full size
Why containers07 / 24

Summary

Three columns. Past (physical servers): wasted, wasted, wasted. Present (hypervisor virtualisation): more efficient than physical servers, but could be better. Present/future (containers): more efficient than hypervisor virtualisation — virtualisation 2.0 — though less mature, with a less mature ecosystem.
Original workshop illustration · View full size
Docker08 / 24

What is Docker?

  • Docker Inc — started as dotCloud, pivoted into containers
  • Dock worker > Docker — dock workers are people who work on transport containers
  • Early days concentrated on building the community and the Docker stack
  • Now is focused on enterprise container management
  • Docker the technology — open source, available on GitHub — https://github.com/docker/docker-ce
The Docker logo: a whale carrying a stack of shipping containers above the word “docker”.
Original workshop illustration · View full size
Docker09 / 24

Docker images

  • Foundational unit of a container
  • Read-only template, and can be the source for multiple containers
  • Key elements:
    • a filesystem, including any relevant application code, packages, libraries, or other dependencies that the container needs to execute correctly
    • metadata such as environment variables or ports to expose, which can influence how the container is run
    • a command, which determines what process gets executed when the container is invoked
Three icons: a filesystem with application code and dependencies; metadata, which influences how a container runs; and a command, executed as a process on invocation.
Original workshop illustration · View full size
Docker10 / 24

Anatomy of a Docker image

  • A JSON object that serves to define the image.
  • It has two key components:
    • Configuration object: governs how the container will operate — the ports to be exposed, the command to be executed as the container’s process, the environment variables, etc.
    • Root filesystem object: an ordered list of references, each of which points to a set of files and directories that collectively are referred to as a layer.
    • After an image is created or pulled from the registry, the associated filesystem layers are stored locally as independent directories, identified by a 256-bit hash of the layer content — a digest.
    • The layers are chained to each other and are read-only, except for the topmost layer, which is read-write.
    • Any change made to a file in a lower layer is done by first copying the file to the topmost layer and then making the edit. This is called copy-on-write.
A base image, a Dockerfile and artefacts combine into my_image, built with the command “docker image build --tag my_image .”
Original workshop illustration · View full size
“Image chain”: each build step produces an image, each image references its parent, and the initial build creates the image chain.
Original workshop illustration · View full size
Docker11 / 24

Building a Docker image

Two different techniques for creating Docker images:

  • Running a container, executing commands within the container, and then committing any changes made to the container’s filesystem to a new Docker image.
    • An ad hoc technique that uses the docker commit CLI command
    • Often results in suboptimal Docker images
  • Building an image based on a sequence of instructions in a special file called a Dockerfile.
    • Dockerfile instructions are executed using the docker build CLI command
    • Leads to images optimised for running specific application services
    • The recommended method for authoring Docker images
Docker12 / 24

Docker registry

Think of it like a GitHub for Docker images.

It contains a set of Docker repositories. A Docker repository is a set of related Docker images.

Docker runs the most popular Docker registry, called Docker Hub.

Ideally your Docker image should reside in a Docker registry with the appropriate tags.

A Docker Hub registry holding Ubuntu, Cassandra and Jenkins repositories, each listing image IDs and tags such as “xenial, 16.04, latest” and “alpine, 2.60.1-alpine”.
Original workshop illustration · View full size
Docker13 / 24

Let’s have a quick break for tea…

Kubernetes14 / 24

What is Kubernetes?

  • Started at Google as an open-source successor to their internal projects, Borg and Omega. Open-sourced by Google in 2014.
  • Kubernetes orchestrates computing, networking, and storage infrastructure on behalf of user workloads.
  • Kubernetes is comprised of a set of independent, composable control processes that continuously drive the current state towards the provided desired state.
  • The name Kubernetes originates from Greek, meaning helmsman or pilot, and is the root of governor and cybernetic. K8s is an abbreviation derived by replacing the 8 letters “ubernete” with “8”.
  • Part of the Cloud Native Computing Foundation — a series of projects that build tools for the cloud.
The Kubernetes ship’s-wheel logo surrounded by turning gears and a cube.
Original workshop illustration · View full size
Kubernetes15 / 24

Kubernetes containers can run wherever a cluster can be set up

The same app definition — scale 10, version 1.4.6, port 443, with Nginx, Redis and MySQL — deployed unchanged to a cloud, an on-premises data centre, and another cloud.
Original workshop illustration · View full size
Kubernetes16 / 24

From hardware to a cluster

A server, a laptop, a phone and a smartwatch each become a node with its own CPU and RAM — from a 64 GB server down to a 512 MB ARM device — and the nodes join one Kubernetes cluster that uses both local disks and cloud storage such as S3.
Original workshop illustration · View full size
Kubernetes17 / 24

Pods, deployments and ingress

A web app pod (Nginx, Node and Redis containers) and a database pod (a PostgreSQL container with a data volume), deployed as two replicas each, spread across nodes with their own IP addresses, behind an ingress / load balancer.
Original workshop illustration · View full size
Kubernetes18 / 24

Kubernetes orchestration

A web API reaches a front end (Nginx) and, internally, a back end (MySQL), each with CPU and RAM allocations; Kubernetes places their containers across a row of nodes in the cloud or on-premises.
Original workshop illustration · View full size
Kubernetes19 / 24

Break for lunch…

Hands on20 / 24

Kubernetes cluster setup

Hands-on coding

Hands on21 / 24

Deploying a container to Kubernetes

Hands-on coding

Hands on22 / 24

Break for tea…

What next23 / 24

What next? Some avenues to explore

What next24 / 24

Thank you