Local Kubernetes: what to pick for your machine

You can read the Kubernetes theory in an evening. Your fingers won't learn to type kubectl from that. The gap between "I understand what a Deployment is" and "I can fix one" only closes once you have a live cluster at hand that you don't mind breaking.

A local cluster is exactly that kind of sandbox. It comes up on your laptop in tens of seconds, goes away with one command, and nobody will notice if you take down its control plane.

Concepts

• Cluster — a control plane plus one or more nodes.
• control plane — the cluster's management layer: api-server, etcd, scheduler, controller-manager.
• Node — a machine in the cluster that runs Pods. Each node runs kubelet, the Kubernetes agent.
• Container runtime — the program that runs containers: Docker, Podman, containerd.
• Version skew — the allowed difference in minor versions between the cluster's components and the kubectl client.

What a 'local cluster' even means

Local tools all solve the same problem: where to get nodes on one machine. There are three answers.

Container nodes. kind and k3d run each node as a plain container in Docker, Podman, or nerdctl. They start the fastest, because there's no VM to bring up. Several nodes here just means "start one more container". The price for the speed: on macOS and Windows the containers live inside the runtime's hidden VM, so the nodes aren't reachable by IP from the host, and you have to forward ports explicitly.

VM nodes. minikube can do this too: the kvm2 driver on Linux, vfkit on macOS, and hyperv on Windows bring up a real VM without Docker. It starts slower, but the node behaves closer to a real server. In practice minikube is most often run with the docker driver, which puts it in the first family instead. The hyperkit driver is deprecated and no longer in Homebrew. VirtualBox on Apple Silicon Macs only started working with minikube v1.39.0 and VirtualBox 7.1+.

A whole ready-made environment. Docker Desktop, Rancher Desktop, OrbStack, and colima install the container runtime and the cluster as one package, and the cluster turns on with a checkbox or a flag. The first three ship with a GUI, colima is driven from the command line. Handy when you don't want to assemble the environment piece by piece. The cost: the vendor often picks the Kubernetes version for you, and a multi-node cluster is unavailable almost everywhere.

k3s deserves a separate mention. It's a full Kubernetes distribution in a single binary, not a wrapper. It installs directly on the host and works only on Linux. For a Linux laptop or a training VPS it's a great option; it doesn't exist on macOS or Windows.

The three tools people actually choose between

There are many ways to run Kubernetes locally, but for learning, the choice comes down to three. All three are free, and all three support multi-node clusters.

Tool	What it runs	Ingress
kind	container nodes with plain Kubernetes	after running a separate cloud-provider-kind program
k3d	container nodes with k3s	right away, Traefik ships with k3s
minikube	a container or a virtual machine	turned on with an addon

Versions, flags, and commands for each live in their own lessons in this track: covering them here would go stale before you finish reading.

The difference between them is smaller than it looks. kind is closest to plain Kubernetes and gets fresh versions fastest. k3d brings up a cluster in seconds and ships with Traefik and storage out of the box, but k3s differs a bit from vanilla Kubernetes. minikube is older and slower, but can run in a virtual machine where there's no container runtime available.

Ready-made apps with Kubernetes built in (Docker Desktop, Rancher Desktop, OrbStack, colima) get their own separate lesson, which also covers licensing and limits. If you already have one of these installed, you can turn the cluster on with a checkbox and install nothing new.

It's worth knowing about Ingress in minikube ahead of time. The classic ingress addon deploys ingress-nginx, and the kubernetes/ingress-nginx repo was archived on March 24, 2026: no more releases, bug fixes, or security patches. Tolerable on a training cluster, not something you'd carry into production. Since v1.39.0, minikube has a Traefik addon. Details, and what to replace ingress-nginx with, are in the lesson on addons.

Licensing, in short

kind, k3d, and minikube themselves are free with no strings attached, same as k3s, colima, and Rancher Desktop. For learning at home, everything is free, including Docker Desktop and OrbStack.

The question comes up on a work laptop. Docker Desktop is paid for companies with 250+ employees or $10M+ in annual revenue. OrbStack costs $8 per user per month for commercial use. Exact terms are covered in the lesson on GUI apps.

How long you wait for startup

The only measured numbers come from minikube's official time-to-k8s benchmark, version v1.36.0:

Tool	Time to a ready cluster
k3d v5.8.3	19.9 s
kind v0.29.0	33.0 s
minikube v1.36.0	50.8 s

Measured on linux/amd64. There are no published numbers for macOS or Windows, and each of those adds its own VM on top of every option, so you can't carry these seconds over to a MacBook directly. The order holds: container nodes come up faster than VM nodes.

What to pick for your OS

macOS on Apple Silicon: kind. Free, gives you a fresh Kubernetes version out of the box, supports multiple nodes, arm64 node images are ready. kind itself isn't a runtime: it needs Docker, Podman, or nerdctl underneath it. If Docker Desktop doesn't fit your license, colima or Rancher Desktop will give you a runtime, both free.

Windows: kind on top of whatever you install. Check the requirements first. Docker Desktop wants Windows 10 22H2 or Windows 11 23H2+, the Pro, Enterprise, or Education edition, 8 GB RAM, and WSL2. Rancher Desktop's requirements only mention Windows 11. If Docker Desktop doesn't fit your license, the working path is Podman Desktop plus the kind CLI. You also need to switch the Podman machine to rootful mode, otherwise kind won't create a cluster on Windows.

A separate note on WSL2: its kernel is missing the xt_recent module. Because of that, a Service with sessionAffinity: ClientIP doesn't work, and neither does any Service created after it. Easy to run into, with a cause that isn't obvious.

Linux: kind or k3d for throwaway clusters, k3s for the long haul. Everything's available, no VM needed. If the cluster lives for weeks and needs to behave like a real server, install k3s: it installs with one command and connects a second host through the K3S_URL and K3S_TOKEN variables.

The cluster version should stay close to production

A local cluster earns its keep when it reproduces what you run in production. If production runs 1.35 and you're training on 1.37, some API fields and behavior will differ, and debugging at home will stop predicting debugging at work.

The Kubernetes project actively supports the three most recent minor branches, each for about 12 months. An outgoing branch gets patches in maintenance mode for two more months. State as of 2026-10-09:

Branch	Latest patch	End of support
1.37	v1.37.1	2027-10-28
1.36	v1.36.5	2027-06-28
1.35	v1.35.9	2027-02-28
1.34 (maintenance mode)	v1.34.12	2026-10-27

Patches come out roughly once a month, so the numbers in this table go stale fast. Check current ones at kubernetes.io/releases.

You can set the version explicitly almost everywhere:

kind create cluster --name lab --image kindest/node:v1.35.0
k3d cluster create lab --image rancher/k3s:v1.36.4-k3s1
minikube start --kubernetes-version=v1.35.0 --driver=docker

For kind, the node image is tied to the kind release: each release's description lists the ready-made images, pick from there. For example, kind v0.33.0 is built with kindest/node v1.37.0, v1.36.4, v1.35.8, and v1.34.11.

Rancher Desktop has its own quirk: workloads survive a Kubernetes version upgrade but get removed on a downgrade.

One more trap: minikube's docs are built from the master branch and can run ahead of the release. That happened in summer 2026: the site already described v1.37.0, while release v1.38.1 still installed v1.35.1 by default. They matched up again in v1.39.0. Check the version against your own binary (minikube version), not the site.

The client version lives separately from the cluster version. The version skew policy allows kubectl to differ from the api-server by no more than one minor version in either direction. With a 1.37 cluster, clients 1.36, 1.37, and 1.38 all work. The other components have their own rules: kubelet can lag behind the api-server by three minor versions, controller-manager and scheduler by one, and none of them can be newer than the api-server.

The next lesson covers kubectl, kubeconfig, and switching between clusters.

Common mistakes

• Taking the version from the site instead of the binary. A tool's docs can describe a release that hasn't shipped yet. Check kind version, minikube version, kubectl version.
• Feeding kind a node image from a different release. The kindest/node image is built for a specific kind release. An image that's too new may fail to boot on an old kind.
• Training on a version that's not in production. API fields and behavior change between minor versions, keep your local version close to production.
• Forgetting about kubectl. A fresh cluster plus an old client outside the one-minor-version range produces strange errors and warnings.
• Expecting to see a kind node by IP from Mac or Windows. The nodes live inside the runtime's VM, ports need explicit forwarding.

What you'll need for the tasks

• Lab 1 needs no cluster: a browser and the Version Skew Policy page.
• Lab 2 brings up a kind cluster on your laptop. You'll need Docker, kind, and kubectl. From the command line you just need docker ps, kubectl get nodes, and kubectl version.