Docker Fundamentals Before You Learn Kubernetes

Why should I learn Docker before Kubernetes?

Because Kubernetes orchestrates containers at scale, and it assumes you already understand how one container is built, shipped, and run. If you jump into pods, deployments, and services without the container mental model, every abstraction feels arbitrary. The Build-Ship-Run framework gives you that model on Day 1 of a CKA journey: BUILD an image from a Dockerfile, SHIP it via a registry, RUN it as a container.

When you later write a Kubernetes manifest that references an image pulled from Docker Hub or an Artifact Registry, you're just doing the pull-and-run stage you already understand — spread across a cluster of nodes.

What is the Docker component model I need to memorise?

For the exam and for real debugging, internalise the full flow:

Docker Client → Docker Daemon (dockerd) → local image storage → registry → Docker Daemon on target → Container Runtime → running container.

Each command maps to a component:

- `docker build` — the Daemon reads the Dockerfile and writes an image to local storage.

- `docker push` — the Daemon uploads the image to a registry.

- `docker pull` — the Daemon on a target host retrieves the image.

- `docker run` — the Daemon instructs the Container Runtime to spin up the container.

The container runtime is critical for CKA, because Kubernetes talks to a container runtime (via the CRI) on every node. Understanding that the runtime is the low-level component that actually launches containers demystifies how Kubernetes schedules workloads.

How do containers differ from VMs, and why does it matter for orchestration?

Containers share the host OS kernel — like flats sharing one building and land — while VMs each carry a full isolated OS like separate houses on separate plots. This is why you can pack, say, 20 microservices as 20 containers on one server efficiently, whereas 20 VMs would waste CPU and memory per instance.

This density model is the entire reason Kubernetes exists: it schedules many lightweight containers across a cluster and lets each consume only the resources it needs. Grasping the Shared Infrastructure, Isolated Tenants principle now makes Kubernetes resource requests, limits, and bin-packing intuitive later.

How do I practise the workflow for the CKA?

Work the seven-step workflow end to end on a real app:

1. Diagnose an environment-promotion problem.

2. Author a single `Dockerfile` (capital D, no extension).

3. `docker build` the image.

4. `docker push` to a registry.

5. `docker pull` on a target environment.

6. `docker run` to launch the container.

7. Validate the flow against the component model.

Do this until each command's component owner is second nature. Then note the pitfalls that also bite in Kubernetes: never bypass the registry, never confuse an image with a running container, and never assume a container carries a full OS.

What Docker terms will I keep seeing in Kubernetes?

Lock in the glossary: Docker image (the shippable, versioned package), Docker container (a running instance), Docker registry (version control for binaries), Docker Daemon (executes commands), and Container Runtime (spins up containers). Kubernetes reuses image and registry concepts directly, and its node components delegate to a container runtime — so this vocabulary transfers almost one-to-one.

Next step: Containerise one small app end to end today, then draw the component-model diagram from memory. Once you can trace build, push, pull, and run to their owning components without looking, you're ready to move into pods and the Kubernetes control plane.