Why Kubernetes Exists, Starting from a Single Container

In this module, you'll learn to:

• Explain what an image, a container, and a registry are
• Name the problems that appear when you run many containers on many machines
• Describe what Kubernetes does about each one, and when you don't need it

Before you start: nothing. You only need to be comfortable typing commands into a terminal. Every other idea in this track is explained when it first comes up. If the Linux side is new to you, the Linux for DevOps track covers it, and its Containers from Scratch module shows what a container really is underneath.

The five-minute version

Kubernetes runs containers, so start there. A container is your application packaged together with everything it needs to run: the runtime (Python, Java, Node.js), libraries, and config files. Because it carries all of that with it, it runs the same way on your laptop, on a test server, and in production. "It works on my machine" stops being a problem.

Three words cover most of it:

• Image: the package. A read-only snapshot of your app and its dependencies, built once from a recipe called a Dockerfile.
• Container: a running copy of an image. You can start many containers from one image, and each is isolated from the others.
• Registry: where images are stored and shared, such as Docker Hub or Amazon ECR. Servers pull images from a registry, the way a phone downloads an app from a store.

# A Dockerfile: the recipe for an image
# Start from an image that already has Python
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
# The app listens on port 8080
EXPOSE 8080
# What runs when the container starts
CMD ["python", "app.py"]

If you've never run a container, install Docker Desktop (or Docker Engine on Linux). The Try it section at the end of this module runs a web server in one command, without installing the web server itself. That's the whole idea.

One container is easy, hundreds are not

Running one container on one machine is simple. Now imagine a real system: twenty services, each needing three copies for reliability, spread over ten servers. Suddenly you have questions that docker run doesn't answer:

• Where should each container run? Which server has enough free CPU and memory right now?
• What happens when one crashes, or a whole server dies at 3 a.m.? Who restarts it, and where?
• How do services find each other when containers move between servers and change IP addresses?
• How do you release a new version without taking the service down?
• How do you handle more traffic? Who starts more copies, and stops them again later?
• Where do passwords and settings go, without baking them into every image?

Answering these by hand, with scripts and spreadsheets of which container runs where, works for a while and then falls apart. A system that answers them for you is called a container orchestrator. Kubernetes is the one that won.

What Kubernetes does for you

Kubernetes turns a group of servers into one pool of capacity, called a cluster. You don't tell it which server to use. You describe what you want ("three copies of orders-api:1.4, reachable at the name orders-api"), and Kubernetes makes it happen and keeps it true.

When you don't need Kubernetes

Kubernetes is powerful, but it's also a platform you have to run and understand. It's not always the right choice:

• One or two small services: a single virtual machine, or a simpler container service such as AWS App Runner or Amazon ECS, is less work.
• Event-driven tasks that run for seconds at a time often fit serverless functions (AWS Lambda) better.
• A small team with no one to own the platform may spend more time running Kubernetes than building the product.

It earns its place when you have many services, several teams, a need for consistent deploys across environments, or the scale where automation stops being optional. That's the situation the later parts of this track describe.

Words you'll meet in the next modules

You don't need to memorise these. Each one gets its own explanation later; this is just so they look familiar.

Run, stop, and inspect a container

With Docker installed, these commands show the image, container, and registry ideas from the top of this module:

# Pull an image from Docker Hub (a registry) and run it as a container
docker run -d --name web -p 8080:80 nginx:1.27

# See running containers, and the images you have locally
docker ps
docker images

# Read the container's logs, then stop and remove it
docker logs web
docker stop web
docker rm web

Now picture doing that by hand for sixty containers across ten machines, every day. The next module gives you a real Kubernetes cluster to do it for you, on your own laptop, for free.

Key terms

• Image: a read-only package of an app and everything it needs, built from a Dockerfile.
• Container: a running, isolated copy of an image.
• Registry: a store that machines pull images from, such as Docker Hub or Amazon ECR.
• Container orchestrator: software that places, restarts, connects, and scales containers across many machines.
• Cluster: a group of machines that Kubernetes manages as one pool of capacity.

Pop quiz

Five questions: three on the ideas in this module, and two scenarios where you apply them. The order changes every time you take it, and 4 out of 5 passes.