From Docker to Kubernetes: What Actually Changes
A short orientation chapter, not a Kubernetes course — it answers the two questions a Docker-focused engineer actually has before starting Kubernetes Mastery: does my Docker knowledge still apply, and what's the one new idea I need before I go deep.
Docker (the Engine) builds and runs individual containers on one machine. Kubernetes is a separate system that schedules and supervises containers across a whole cluster of machines — it doesn't replace Docker, it operates a fleet built from the exact same images docker build produces.
Everything you already know so far — Dockerfiles, image layers, multi-stage builds, networking concepts, Compose's service/health-check model — carries over directly; Kubernetes just re-implements the equivalent of "run these containers, keep them healthy, give them a stable address" at cluster scale, with its own object model (Pods, Deployments, Services) instead of a Compose file. That object model, and everything you can do with it, is the actual subject of Kubernetes Mastery — this chapter's only job is to remove the one piece of confusion that trips up Docker-first engineers before they start it.
Kubernetes removed direct integration with the Docker Engine (dockershim) in version 1.24 — a change that got reported as "Kubernetes drops Docker support" and confused a lot of people who'd built their whole workflow around docker build. What actually changed: the kubelet (each node's agent) used to talk to the Docker Engine through an extra translation layer called dockershim; it now talks directly to a Container Runtime Interface implementation, almost always containerd — which, not coincidentally, is the same runtime Docker Engine itself uses internally.
What did NOT change: the image format. OCI-compliant images built by docker build run on a containerd-based Kubernetes node without any modification, because the image spec was always a standard, not a Docker-proprietary format. Your Dockerfiles, your CI pipeline's docker build/docker push steps, your registry — none of that needs to change to target Kubernetes.
-
Your Dockerfile, build, and push steps stay identical — nothing here is Kubernetes-specific.
-
Instead of a
docker-compose.ymldescribing services/networks/volumes, you write Kubernetes manifests (a Pod's shape, replica count, networking) — a different object model expressing similar intent. -
Instead of
docker compose up, youkubectl applythose manifests to a cluster, and a set of controllers continuously reconciles the cluster toward what you declared.
The mechanics of that object model — Pods, Deployments, Services, rolling updates, probes — are covered properly, with real depth, in Kubernetes Mastery. This chapter stops here on purpose.
-
A team that's been running the Spring Boot stack from Chapter 9 locally with Compose, moving the same images to a multi-node cluster once a single Docker host can no longer handle production traffic or needs to survive a node failing.
-
A CI pipeline that already builds and pushes images for local Compose use adding one more step — applying a Kubernetes manifest referencing the same image tag — with no change to the build stage at all.
-
Don't re-learn container fundamentals for Kubernetes — everything from Chapters 1–9 (images, layers, multi-stage builds, networking concepts, health checks) transfers directly; what's new is purely the orchestration layer on top.
-
If a container behaves differently under Kubernetes than it did under
docker run/Compose, suspect the orchestration layer (probes, resource limits, network policy) first — not the image itself, which is unchanged.
-
Believing Kubernetes "doesn't support Docker anymore" after the dockershim removal — Kubernetes runs the exact same OCI images Docker builds; only the node-level component talking to the runtime changed (from dockershim+dockerd to containerd directly).
-
Assuming you need to rebuild or restructure existing Docker images to run on Kubernetes — a working image needs zero changes; only how you run it changes.
Everything from Chapters 2, 3, 11 and 12 on image size, layer caching, and multi-stage builds matters just as much on Kubernetes — a smaller image still pulls and starts faster, on any node, in any orchestrator. Cluster-scale performance topics (autoscaling, resource requests/limits, scheduling) are Kubernetes Mastery's subject, not this chapter's.
Treat this chapter as a bridge, not a destination — if you're taking a service to production on Kubernetes, go through Kubernetes Mastery's workloads, networking, scaling, and production chapters before you rely on a cluster for anything real. What transfers from here is your Docker foundation; the operational judgment for running it well at cluster scale is a separate, deeper subject.
-
Take an image you already built earlier in this course and run it with a single, minimal
kubectl run <name> --image=<your-image>against any test cluster (Minikube, kind, or a cloud sandbox) — confirm it runs with zero changes to the image itself. -
Run
kubectl describe nodeon that cluster and find theContainer Runtime Versionfield — confirm it says containerd (or CRI-O), not "docker," and connect that back to this chapter's dockershim explanation.
-
Docker builds and runs individual containers; Kubernetes orchestrates fleets of them across a cluster of nodes — it's a different layer, not a replacement.
-
dockershim removal (K8s 1.24) changed only the internal runtime communication path (now direct to containerd) — OCI images built by Docker are completely unaffected.
-
Every Docker skill you've learned so far — Dockerfiles, layers, multi-stage builds, networking, health checks — transfers directly; Kubernetes' own object model (Pods, Deployments, Services) and everything built on it is covered in depth in Kubernetes Mastery.
Want a visual for this concept?
Generate a diagram tailored to “From Docker to Kubernetes: What Actually Changes” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.
Sign in to generate a visual →