Docker vs Kubernetes: What Homelab Beginners Need to Know

If you have spent any time in homelab forums, you have seen Docker and Kubernetes mentioned in the same breath. They are related, but they solve different problems. This post explains what each one does, how they differ, and how to start learning them without buying a rack of hardware.

The short version

Docker packages and runs applications in containers on a single machine. Kubernetes manages containers across a group of machines, deciding where they run and restarting them when something fails.

A useful analogy: Docker is the shipping container and the tool that builds and runs it. Kubernetes is the port authority that decides which ship carries which container, and what to do when a ship breaks down.

They are not direct competitors. Kubernetes needs a container runtime to actually run containers, and the images you build with Docker work with Kubernetes.

What Docker does

A container is a process (or group of processes) isolated from the rest of the system, bundled with the files and libraries it needs. Because everything the app needs is in the package, it runs the same way on your laptop, a mini PC, or a VM.

Docker gives you the main building blocks:

• Image: a read-only template containing your app and its dependencies.
• Container: a running instance of an image.
• Dockerfile: a text recipe for building an image.
• Registry: a place to store and pull images, such as Docker Hub.
• Docker Compose: a tool for describing a multi-container app in one YAML file.

Here is a single command that runs a web server:

docker run -d --name web -p 8080:80 nginx:stable

That pulls the image if needed, starts it in the background, and maps port 8080 on your host to port 80 in the container. Browse to port 8080 on that machine and you will see the nginx welcome page.

For anything with more than one piece, Compose is the natural next step:

services:
  web:
    image: nginx:stable
    ports:
      - "8080:80"
    restart: unless-stopped

Save that as compose.yaml and run docker compose up -d. One file now documents how the service runs, which is a big improvement over a pile of remembered commands.

What Kubernetes does

Kubernetes (often written K8s) is an orchestrator. You do not tell it to start a container. You tell it what state you want, for example "run three copies of this app," and it works continuously to make reality match.

A few core concepts:

• Cluster: the set of machines Kubernetes manages.
• Node: one machine in the cluster.
• Pod: the smallest deployable unit, usually one container (sometimes a few that work closely together).
• Deployment: a declaration of how many pod replicas you want and how to update them.
• Service: a stable network address that routes traffic to a changing set of pods.
• Namespace: a way to separate groups of resources inside one cluster.

This is the declarative model. If a pod crashes, Kubernetes starts a replacement. If a node goes offline, pods are rescheduled onto healthy nodes. If you change the image version in a Deployment, it can roll the update out gradually.

A quick taste with kubectl, the command line client:

kubectl create deployment web --image=nginx:stable --replicas=2
kubectl expose deployment web --port=80 --type=NodePort
kubectl get pods

In practice most people write YAML manifests and apply them with kubectl apply -f, so the configuration can live in version control.

Key differences

	Docker	Kubernetes
Main job	Build and run containers	Orchestrate containers across machines
Scope	Usually one host	A cluster of one or more nodes
Config style	Commands or Compose files	Declarative YAML manifests
Self-healing	Basic restart policies	Reschedules and replaces failed workloads
Scaling	Manual, or limited in Compose	Built in, including across nodes
Learning curve	Gentle	Steep
Resource overhead	Low	Higher, especially the control plane

One more detail that trips up beginners: Kubernetes does not require Docker Engine. It talks to container runtimes through an interface, and clusters commonly use containerd or CRI-O. Images built with Docker still run fine, because they follow the standard image format.

Do you need Kubernetes at home?

Honest answer: probably not for running your services. If you have one or two machines hosting Jellyfin, a DNS filter, a password manager and a few other apps, Docker with Compose is simple, well documented, and easy to back up.

Kubernetes makes sense in a homelab when:

• You want to learn it for work or certification.
• You run several nodes and want workloads to move between them automatically.
• You like managing everything as code and want a GitOps workflow.

Learning Kubernetes is a perfectly good reason to build a cluster. Just be clear that you are doing it for the learning, and expect to spend time on networking, storage and upgrades.

Getting started

Step 1: Learn Docker first

Install Docker Engine on a Linux VM or spare machine, or use Docker Desktop on Windows or macOS. Then practice:

1. Run a few containers from public images.
2. Learn volumes, so data survives when a container is removed.
3. Learn port mapping and basic container networking.
4. Write a small Dockerfile for a simple app of your own.

Step 2: Move your services to Compose

Pick two or three services you already run and describe them in Compose files. Keep the files in a Git repository. You will find that the habits you build here, such as pinning image versions and keeping config out of containers, carry straight over to Kubernetes.

Step 3: Try a small Kubernetes cluster

You do not need multiple servers to begin. Common options for learners:

• kind: runs a cluster inside Docker containers, good for quick experiments.
• minikube: a local single-node cluster for learning.
• k3s: a lightweight Kubernetes distribution that suits mini PCs and Raspberry Pis, and can grow to multiple nodes.

Once a cluster is running, work through this order:

1. Deploy an app with a Deployment and expose it with a Service.
2. Scale it up and down, and delete a pod to watch it come back.
3. Move the configuration into YAML files and use kubectl apply.
4. Learn ConfigMaps and Secrets for configuration.
5. Learn persistent volumes, then ingress for routing web traffic.

Step 4: Break things on purpose

Stop a node, push a bad image tag, or fill a disk. Watching how Kubernetes reacts teaches more than reading docs, and a homelab is the right place for it.

Common beginner mistakes

• Starting with Kubernetes. Without container basics, the error messages make little sense.
• Using the latest tag. Pin versions so updates are deliberate.
• Ignoring storage. Containers are disposable, so decide where your data lives and back it up.
• Exposing services carelessly. Do not publish admin interfaces to the internet without authentication.
• Skipping backups of manifests. Keep your Compose files and YAML in Git.

Conclusion

Docker is how you package and run containers. Kubernetes is how you manage many of them across many machines. Start with Docker and Compose, get comfortable with images, volumes and networking, and then try a small Kubernetes cluster with kind, minikube or k3s when you are ready to learn orchestration. Your next step: pick one service you run today, put it in a Compose file, and commit it to Git.