Running local Kubernetes on your own machine is the fastest way to actually learn the technology. You don't need a server farm for it: Minikube, kind and k3s start a complete cluster in a container or a small VM on your laptop, and you work on it with the same kubectl you'll use in production later. Which tool fits depends on whether you want to learn, simulate several nodes or keep something running permanently.
A local cluster is only a simulation of a distributed system. Compute and size end at your machine, and some topics like node failures or real networking between servers can only be reproduced to a limited degree. For almost everything you'll do with Kubernetes in your first months, that's still more than enough.
I run Kubernetes clusters in production, and my Kubernetes practical guide with Rheinwerk Computing (2024) is built entirely on a local Minikube, because every reader can get started with it right away. All my articles on the topic are collected on the Kubernetes page.
Which tool for which purpose: Minikube, kind, k3s or Docker Desktop
All four tools give you a real Kubernetes API server that kubectl cannot tell apart from a cluster in the cloud. The difference lies in how they build the cluster, how many nodes they support and what comes bundled with them.
| Tool |
How the cluster runs |
Multiple nodes |
What I use it for |
| Minikube |
One container or VM, optionally several |
yes, with --nodes |
Learning, book examples, addons like registry, ingress and dashboard |
| kind |
Every node is a Docker container |
yes, via a YAML file |
Multiple nodes without hardware, tests in CI pipelines |
| k3s |
A single binary directly on the operating system |
yes, server and agents |
Permanent operation on Linux servers and Raspberry Pis |
| Docker Desktop |
A cluster inside the Docker VM, enabled with a switch |
no |
Quick test when Docker Desktop is running anyway |
My recommendation for getting started is Minikube. It works the same way on all three operating systems, ships the most useful extensions and has error output that tells you what to do. You pick kind when you specifically need several nodes or want to spin up a cluster inside a pipeline. k3s is the tool when the cluster is supposed to live on a small server or Raspberry Pi rather than on your laptop.
Prerequisites on macOS, Windows and Linux
For Minikube and kind you need a running Docker Engine. On macOS and Windows that usually means Docker Desktop. Check beforehand whether you need a license for it: Docker Desktop is paid for larger companies, and the terms change from time to time. Alternatives like Podman or Colima work with Minikube as well, but this guide sticks with Docker because it brings the fewest surprises.
On Linux the Docker Engine without the desktop UI is enough. If you want to use k3s, you don't even need Docker: k3s ships its own container runtime.
A note from many training sessions: company laptops with strict security policies are a frequent problem for these instructions. Restricted permissions, blocked ports or a proxy that prevents image downloads often cost more time than the actual installation. If you can, use a machine your IT department doesn't manage. If you can't, talk to your administrator first.
For resources, the Minikube documentation lists two CPU cores, 2 GB of free memory and 20 GB of disk space as the minimum. In practice, memory is the bottleneck: as soon as you deploy a real application with a database, you'll want to give the cluster more. On Apple Silicon Macs, Minikube runs natively as the ARM variant, which you need to keep in mind when downloading it by hand.
|
Minikube |
k3s |
| Built for |
development on your own machine |
running permanently on small hardware |
| Runs in |
a VM or a container |
directly on the operating system |
| Throwing the cluster away |
minikube delete, seconds |
uninstall on every node |
| Multiple nodes |
possible, but rarely needed |
the normal case |
| Right when |
you want to try out a manifest |
you want to keep something running |
If you only want to test a manifest, stay with Minikube. If you want a cluster running for weeks, you are better off with k3s on your own hardware, and the build is described in Kubernetes on a Raspberry Pi.
Installing Minikube and starting local Kubernetes
On the Mac, Homebrew is the easiest route, on Windows the package manager winget or Chocolatey, on Linux the package for your distribution. All variants are listed in the Minikube documentation, here are the three I use most often: the first line for macOS with Homebrew, the second for Windows in PowerShell, the last two for Linux on x86-64 as a binary.
brew install minikube
winget install Kubernetes.minikube
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube
The package ID Kubernetes.minikube comes from the Minikube documentation; I work on macOS and Linux myself and have not run the Windows route on my own machine. With minikube version you check that the tool is in your path. Then you start the cluster:
minikube start
On the first start, Minikube downloads the image for the node, which takes a few minutes depending on your connection. After that a Kubernetes cluster runs in a Docker container on your machine, and kubectl get nodes shows you one node in the Ready state. Minikube configures the context in your kubeconfig automatically.
Day to day you need four commands: minikube pause and minikube unpause halt all containers when you don't need the cluster right now and save battery. minikube stop shuts the cluster down cleanly and keeps its state, which is the right command before you call it a day. minikube delete removes everything and gives you a fresh cluster, something you'll need more often than you think.
The easiest way to get your own images into the cluster is to skip the registry entirely. eval $(minikube docker-env) points your Docker client at the Docker daemon inside Minikube, so everything you build after that is already in the cluster and never has to be uploaded anywhere. Set imagePullPolicy: IfNotPresent in the Deployment, otherwise Kubernetes still tries to pull the image from the internet. You have to repeat the eval command in every new shell or put it into your .zshrc or .bashrc. If you would rather have a real registry in the cluster, enable it with minikube addons enable registry.
kind: multiple nodes in Docker containers
kind stands for "Kubernetes in Docker" and does exactly that: every node of your cluster is a Docker container running kubelet and the container runtime. That makes kind very fast to start and very well suited for anything that needs several nodes: scheduling rules, taints and tolerations, DaemonSets or the behavior when draining a node.
You describe the shape of the cluster in a small YAML file. This configuration creates one control plane and two workers:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
Saved as kind-config.yaml, you start the cluster with kind create cluster --config kind-config.yaml. Shortly afterwards kubectl get nodes shows three nodes, and you can practice with kubectl cordon and kubectl drain, for example, how Kubernetes moves Pods around. The details of the configuration are in the kind documentation.
In my projects, kind mostly runs in CI pipelines: a cluster is created for the test run, Helm charts are installed and verified, then everything is deleted again. On the laptop, Minikube is more practical for me because the addons for ingress and registry are ready to go. With kind you have to install an ingress controller yourself and forward ports in the configuration.
k3s vs. k8s: the lightweight route for servers and Raspberry Pi
k3s is not a replacement for Kubernetes but a certified distribution of it. All Kubernetes components are packed into a single binary, it uses SQLite instead of etcd by default, and some rarely used features are removed or moved into extensions. From the point of view of kubectl and your manifests, there is no difference from a full k8s. The difference is in operations: k3s needs far less memory, starts in seconds and installs on ARM boards.
Installing a server is one command:
curl -sfL https://get.k3s.io | sh -
Afterwards the kubeconfig sits at /etc/rancher/k3s/k3s.yaml and the cluster runs as a system service. To attach more nodes, you need the server's token from /var/lib/rancher/k3s/server/node-token and the server's IP address:
curl -sfL https://get.k3s.io | K3S_URL=https://192.168.1.10:6443 K3S_TOKEN=<token-from-server> sh -
That's exactly how I build the cluster of Raspberry Pis I describe in the book, which served as my test environment for years. And in my client projects, k3s runs in production in a German cloud with three control plane nodes across three data centers: the lightweight distribution is not limited to the homelab. If you want k3s inside Docker instead of directly on the operating system, use k3d, which follows the same approach as kind and starts k3s nodes as containers. All options are documented in the k3s project on GitHub.
The first deployment in your local cluster
Whichever tool you picked, from here on everything is the same. A quick test to see whether your cluster really accepts work:
kubectl create deployment hello --image=nginx
kubectl expose deployment hello --port=80 --type=NodePort
kubectl get pods
The Deployment starts a Pod with Nginx, the Service exposes it on a port at the node. With Minikube, minikube service hello opens the browser directly at the right address. With kind and k3s, you read the port from kubectl get service hello and call it via the node's IP.
Once that works, the step to an Ingress is worth it: minikube addons enable ingress installs the Nginx ingress controller, and you can map hostnames to Services with an Ingress resource, just like in production later. With k3s, Traefik is preinstalled as the ingress controller. With these basics you're ready for daily work with kubectl, which I've summarized in kubectl commands: the most important ones for daily work.
Typical errors when starting out
The most common error is a Docker daemon that isn't running. Minikube then reports something like PROVIDER_DOCKER_NOT_RUNNING and the question Is the docker daemon running?. The fix is in the message: start Docker Desktop and run minikube start again. This mostly happens after a reboot when Docker isn't set to start automatically.
The second classic is command not found: minikube right after installation. The binary isn't in your path yet, and a new terminal window usually fixes it. After a manual installation on Windows, check whether the directory is really in the PATH variable.
A third case I see often in training: the cluster starts, but Pods stay in ImagePullBackOff. Almost always a proxy or firewall is blocking the image download. On company machines, this is the moment you need your administrator. And when nothing fits anymore after a lot of experimenting, minikube delete and a fresh start is faster than any debugging.
From laptop to production
The local cluster is the learning environment, not the destination. What works on Minikube usually works in the cloud too, but a few things behave differently: persistent volumes come from a simple hostpath provisioner locally, and from a storage system with very different properties in production. A Service of type LoadBalancer stays without an external IP in Minikube unless you keep minikube tunnel running; k3s ships a small load balancer of its own for this. And the failure of a node can't be simulated with a single container.
That's why I recommend an intermediate step if you're seriously interested in Kubernetes: a small cluster made of several real machines. How I built my cluster of Raspberry Pis with k3s and what you learn about networking, storage and failures along the way is in Kubernetes on the Raspberry Pi. And if you want to understand what actually runs inside those Minikube and kind containers, you'll find the components in Kubernetes Architecture: The Components.
Frequently asked questions
Minikube or kind: which is better for getting started?
For getting started, Minikube. It runs the same way on every operating system, ships registry, ingress and dashboard as addons and gives understandable hints when something fails. kind is better when you need several nodes or want to create the cluster in a CI pipeline. Both can be installed side by side without problems.
Is k3s production-ready or just for the homelab?
k3s is a CNCF-certified Kubernetes distribution and is used in production, including by me. For production you replace SQLite with etcd or an external database and run several server nodes. So the k3s vs. k8s question is less about maturity than about environment: small servers, edge and ARM speak for k3s, large cloud environments for the managed offerings of the providers.
Is Docker Desktop with Kubernetes enabled enough?
For a quick test of whether a manifest works at all, yes. Docker Desktop starts a single-node cluster with a switch in its settings. As soon as you need addons, multiple nodes or a clean reset of the cluster, you're better served by Minikube or kind.
How much memory does local Kubernetes need?
The Minikube documentation lists 2 GB of free memory as the minimum. The cluster runs with that, but not much on top of it. On my laptop, Minikube gets considerably more because I deploy databases and monitoring alongside. How much you really need depends on your applications, not on Kubernetes itself.
What do I need for a Kubernetes homelab?
To begin with, nothing but your machine and Minikube. If you want to build a Kubernetes cluster from real hardware, two to four Raspberry Pis or used mini PCs with k3s are enough. The advantage over the local cluster: real networking, real failures and the option to keep services running permanently.
Where to go next
Start today with minikube start and the Deployment above. Once that runs, work through the most important commands in kubectl commands: the most important ones for daily work and look at Kubernetes Architecture: The Components to see which components are running in your node right now. If the topic grabs you, Kubernetes on the Raspberry Pi is the next step.
In full detail with all examples, from installation on every operating system to the container registry in Minikube, this is covered in chapter 2 of my book "Kubernetes: Practical Guide for Developers and DevOps Teams" (Rheinwerk Computing). You can find all the information about the book on my Kubernetes page.
