What Is Kubernetes?From Docker to Container Orchestration

1. What is Kubernetes?

Kubernetes, often shortened to K8s, is an open-source platform used mainly to manage containers.

Kubernetes was originally built by Google, because Google was running containerized applications at a very large scale.

Put simply:

But before Kubernetes really makes sense, you need to understand two concepts:

1. Containers
2. Container Orchestration

In this part we mainly look at containers, and at Docker in particular.

2. Why do we need Docker?

Before Docker, setting up an application was often very complicated.

Say we have an application made up of:

• Node.js web server
• MongoDB database
• Redis cache/messaging system
• Ansible automation tool

Each of these pieces of software might need:

• A specific operating system version
• A specific library
• Specific dependencies
• A specific configuration

This is where the problems start.

For example:

MongoDB might need version 1 of a library.

But Redis needs version 2 of that same library.

On top of that, one developer uses Ubuntu, another uses Fedora, and the production server might run yet another Linux distribution.

And then comes the familiar problem:

In other words, the application runs on the developer’s computer, but not on the production server.

Docker solves much of this problem.

3. What is Docker?

Docker is a containerization platform.

With Docker, you can put an application together with everything it needs to run into a single package.

For example:

• Application Code
• Runtime
• Libraries
• Dependencies
• Configuration

That way you don’t have to install everything by hand on every computer or server.

You build a Docker image once, and then you can run it on any machine that supports Docker.

For example:

docker run mongodb

docker run redis

docker run node

You don’t need to memorise the commands right now.

Main concept:

In other words:

Build once → run the same way everywhere.

4. What is a container?

A container is an isolated environment for running an application.

A container can have its own:

• Processes
• Network interfaces
• File system mounts
• Libraries
• Dependencies

But here is something very important:

They share the host machine’s OS kernel.

Put simply:

It can look like a separate computer, but it is not actually a full virtual machine.

5. Containers vs Virtual Machines

This is a very important concept for learning Docker and Kubernetes.

How does a virtual machine work?

A virtual machine, or VM, contains:

• Application
• Libraries
• Dependencies
• Full Guest Operating System
• Its own kernel

For example:

Physical Server
      ↓
Hypervisor
      ↓
VM 1
├── Ubuntu OS
├── Kernel
├── Libraries
└── Application

VM 2
├── Ubuntu OS
├── Kernel
├── Libraries
└── Application

Each VM has its own full operating system.

Because of this, a VM usually:

• Uses more RAM
• Uses more CPU
• Needs more disk space
• Takes longer to start

But it has one advantage:

How does a container work?

A container usually contains:

• Application
• Libraries
• Dependencies

But it does not contain:

• Full Operating System
• Its own kernel

All containers share the host’s kernel.

Example:

Physical Server
      ↓
Linux Host OS
      ↓
Docker
      ↓
Container 1
├── App
└── Dependencies

Container 2
├── App
└── Dependencies

Container 3
├── App
└── Dependencies

All of these containers use the same Linux kernel underneath.

Because of this, containers:

• Lightweight
• Fast
• Smaller
• Easy to scale

VM vs container: a simple comparison

An easy way to remember it:

And

6. What does “sharing the kernel” mean?

This concept can be a little confusing at first.

In simple terms, you can think of an operating system as having two parts:

Operating System
│
├── Kernel
│
└── User-space Software / Tools

For example:

• Ubuntu
• Debian
• Fedora
• CentOS
• SUSE

These are different Linux distributions.

But they all share the same base:

Their software, package managers, configuration and so on can differ.

For example:

Ubuntu:

Ubuntu Tools
     ↓
Linux Kernel

Fedora:

Fedora Tools
     ↓
Linux Kernel

Debian:

Debian Tools
     ↓
Linux Kernel

So on a Linux Docker host, you can run all kinds of Linux-based containers.

For example:

Linux Host
    ↓
Docker
    ↓
├── Ubuntu Container
├── Debian Container
├── Fedora Container
└── CentOS Container

Because in the end they are all using the Linux kernel.

What about Windows containers?

Windows uses:

Linux uses:

So, directly:

Linux Kernel
   ↓
Windows Container ❌

This will not work.

Because a Windows application expects a Windows kernel.

In the same way:

So how do Linux Docker containers run on Windows?

In that case, Docker/WSL usually creates a small Linux virtual machine/environment internally.

Conceptually:

Windows
   ↓
Linux VM / WSL2
   ↓
Linux Kernel
   ↓
Docker
   ↓
Linux Containers

That is how you can run Linux Docker containers on a Windows laptop.

7. Docker Image vs Container

This is very important too.

What is a Docker image?

An image is a template, or package.

An image contains the things an application needs to run.

For example, a MongoDB image contains the environment needed to run MongoDB.

Put simply:

What is a container?

A container is:

In other words:

MongoDB Image
      ↓
 docker run
      ↓
MongoDB Container

You can create multiple containers from the same image.

Example:

MongoDB Image
     ↓
├── Container 1
├── Container 2
└── Container 3

Programming analogy

If you know OOP:

Even simpler:

Dockerfile
    ↓
 Build
    ↓
Docker Image
    ↓
 Run
    ↓
Container

This is a very important flow.

Remember:

8. What is a Dockerfile?

A Dockerfile is a text file that tells Docker how to build the application environment.

Example:

FROM node:20

WORKDIR /app

COPY . .

RUN npm install

CMD ["npm", "start"]

Here it is basically saying:

Take a Node.js environment
       ↓
Create an /app directory
       ↓
Copy my code
       ↓
Install dependencies
       ↓
Start the application

Then:

docker build

builds an image from the Dockerfile.

Then:

docker run

runs a container from that image.

So again:

Dockerfile
    ↓
docker build
    ↓
Image
    ↓
docker run
    ↓
Container

9. What is Docker Hub?

Docker Hub is an online registry/repository for Docker images.

Just as you can get code from GitHub, you can get ready-made Docker images from Docker Hub.

For example:

• MongoDB
• Redis
• Node.js
• Ubuntu
• Nginx
• MySQL
• PostgreSQL

Say you need MongoDB.

Traditional way:

MongoDB website
      ↓
Download
      ↓
Install
      ↓
Dependencies
      ↓
Configure
      ↓
Start service

With Docker:

docker run mongo

If the image isn’t on your machine yet, Docker can pull it from Docker Hub automatically.

Conceptually:

Docker Hub
    ↓
MongoDB Image
    ↓
Your Computer
    ↓
MongoDB Container

10. How does Docker help developers and operations?

Traditional software development:

Developer
    ↓
Builds the application
    ↓
Hands the code to operations
    ↓
Operations installs the dependencies
    ↓
Configures production
    ↓
Something breaks

Then the developer says:

Because the development and production environments are not the same.

With Docker:

Developers and the operations team together:

Application
     +
Dockerfile
     ↓
Docker Image
     ↓
Development

Testing

Production

The same image can run in every environment.

This greatly improves consistency.

The key benefit:

11. If we have Docker, why do we need Kubernetes?

Now for the real Kubernetes concept.

Docker is very good at:

But say you don’t have just 2 containers.

You have:

10 servers

100 containers

Or:

100 servers

10,000 containers

Now managing them by hand becomes impossible.

Example:

A container crashes.

Who restarts it?

Traffic goes up.

Who creates the extra containers?

A server crashes.

Who moves that server’s containers to another server?

You need to deploy a new version of the application.

If you update every container at once, the service might go down.

To solve these problems, you need:

And Kubernetes is a:

12. What is container orchestration?

Orchestration means automatically coordinating and managing many containers.

Kubernetes can:

• Start containers
• Stop containers
• Restart failed containers
• Scale the application
• Distribute workloads across servers
• Load balance traffic
• Manage deployments
• Run rolling updates
• Recover from failures
• Maintain the desired state

13. A simple Kubernetes example

Say you have a website.

Normal traffic:

Users
  ↓
Container 1

Container 2

Container 3

Suddenly, on Black Friday, traffic shoots up.

Kubernetes can then automatically go from:

3 Containers
     ↓
Traffic increases
     ↓
10 Containers

And when traffic drops again:

10 Containers
     ↓
Traffic decreases
     ↓
3 Containers

This is called:

14. What happens when a container crashes?

Say you have told Kubernetes:

Now:

Container 1 ✅
Container 2 ✅
Container 3 ✅

Suddenly Container 2 crashes:

Container 1 ✅
Container 2 ❌
Container 3 ✅

Kubernetes detects:

Desired = 3

Actual = 2

Then it creates a new container:

Container 1 ✅
Container 3 ✅
Container 4 ✅

Again:

Desired = 3

Actual = 3

This is one of the fundamental ideas of Kubernetes:

You tell Kubernetes:

Kubernetes constantly works to keep the actual system in that state.

15. The relationship between Kubernetes and Docker

Put simply:

Docker

Question:

Answer:

Kubernetes

Question:

Answer:

Conceptually:

Application
     ↓
Dockerfile
     ↓
Container Image
     ↓
Containers
     ↓
Kubernetes
     ↓
Manage / Scale / Heal / Deploy

16. A very simple real-life analogy

Say you run a restaurant chain.

Docker Image = Recipe

For example:

Container = Actual Burger

The actual burger made by following the recipe.

From one recipe, you can make:

Burger 1

Burger 2

Burger 3

Burger 4

In the same way:

Docker Image
    ↓
Container 1

Container 2

Container 3

Container 4

Kubernetes = Restaurant Manager

Kubernetes keeps an eye on:

• How many customers have come in
• How many burgers are needed
• Which kitchen is free
• Which worker is unavailable
• Where extra production is needed
• Where something has failed

In other words:

17. Another very useful analogy

Imagine:

Virtual machine = a separate house 🏠

Each house has its own:

• Kitchen
• Bathroom
• Electricity system
• Facilities

So the isolation is strong, but it is expensive.

Container = Apartment 🏢

Each apartment is separate.

But everyone in the building shares some of the infrastructure.

Because of this:

18. Important terminology

These terms will come up again and again.

Dockerfile

Instructions for how an image is built.

Dockerfile
↓
Image

Image

An application’s packaged template.

Image
↓
Container

Container

A running instance of an image.

Docker Hub

An online registry where container images are stored.

Host

The machine the containers are running on.

Kernel

The core part of an operating system.

It acts as the interface between hardware and software.

Containerization

The process of packaging an application and its dependencies into a container.

Container Orchestration

The process of managing many containers automatically.

Kubernetes

Container orchestration platform.

19. The whole flow together

Remember this diagram and a lot will fall into place:

Developer writes Code
        ↓
Creates Dockerfile
        ↓
docker build
        ↓
Docker Image
        ↓
Store Image in Registry

e.g. Docker Hub
        ↓
docker run
        ↓
Container
        ↓
Many Containers
        ↓
Kubernetes
        ↓
Manage

Scale

Load Balance

Restart

Deploy

Recover

20. Docker vs Kubernetes in one line

Docker:

Kubernetes:

21. Important difference

What is Docker?

What is a Container?

What is Kubernetes?

Docker vs Kubernetes?

22. The 5 most important things

For now, you only need to keep these 5 concepts in mind:

1. Docker packages the application

App + Dependencies
        ↓
Docker Image

2. Containers are created from images

Image
 ↓
Container

3. Containers are lightweight

Because:

Containers
     ↓
Share Host Kernel

4. A VM has its own operating system and kernel

VM
↓
Guest OS
↓
Own Kernel

But:

Container
↓
No own kernel
↓
Uses Host Kernel

5. Kubernetes manages containers

Many Containers
      ↓
Kubernetes
      ↓
Deploy

Scale

Restart

Load Balance

Recover

Final Simplified Explanation

To put the whole thing very simply:

With Docker, you package an application together with the dependencies it needs into a container image.

From that image, we run one or more containers.

Containers are lightweight because each one does not have its own full operating system. They share the host machine’s kernel.

A virtual machine, on the other hand, has its own guest OS and kernel, which makes it comparatively heavy.

When we need to manage hundreds or thousands of containers across many servers, we use Kubernetes.

Kubernetes can automatically:

deploy → run → monitor → restart → scale → load balance → recover

Finally, just remember this one line:

And the flow:

Code
 ↓
Dockerfile
 ↓
Image
 ↓
Container
 ↓
Kubernetes
 ↓
Manage at Scale