Introduction

Minikube runs a real upstream Kubernetes cluster on your laptop — and despite the name, it hasn't been single-node-only since v1.10 back in 2020. In 2026 it is one of three serious local Kubernetes options alongside kind and k3d, and the right pick depends on what you're doing. One outdated idea to discard first: you do not need a hypervisor. The Docker driver has been minikube's default and preferred driver for years; the cluster runs inside a container on the Docker engine you already have. VirtualBox and Hyper-V remain available as drivers, but they're the legacy path, not a prerequisite.

Installing Minikube

Pick your platform:

# macOS
brew install minikube

# Windows
winget install Kubernetes.minikube

# Linux
curl -LO https://github.com/kubernetes/minikube/releases/latest/download/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

If you don't have kubectl installed, minikube bundles one — run it as minikube kubectl -- get nodes, or add an alias and forget about it.

Quickstart: Zero to a Running Service

Start the cluster and deploy something — a tutorial that stops at kubectl get nodes hasn't shown you Kubernetes yet:

minikube start --driver=docker
kubectl get nodes

kubectl create deployment web --image=nginx:1.27
kubectl expose deployment web --type=NodePort --port=80
minikube service web

That last command opens the service in your browser, tunneling to the NodePort inside the cluster. From there, the addons are where minikube earns its place — one command each for pieces you'd otherwise install by hand:

minikube addons enable ingress
minikube addons enable metrics-server
minikube dashboard

The step that trips most newcomers is running your own code: the cluster cannot see images that only exist in your host's Docker daemon, so a plain kubectl create deployment against a locally built tag fails with ImagePullBackOff. Either load the image into the cluster after building, or point your shell's Docker client at minikube's runtime and build directly inside it:

# option 1: build on the host, then copy in
minikube image load shop-api:dev

# option 2: build straight into the cluster's runtime
eval $(minikube docker-env)
docker build -t shop-api:dev .

Either way, set imagePullPolicy: IfNotPresent on the deployment so Kubernetes uses the local image instead of trying to pull it from a registry.

Want to rehearse scheduling behavior, pod disruption budgets, or node failure? Create a multi-node cluster, and pin the Kubernetes version to match production:

minikube start --nodes 3 --kubernetes-version=v1.33.1 -p lab
kubectl get nodes
minikube stop -p lab      # pause the cluster
minikube delete -p lab    # remove it entirely

Minikube vs kind vs k3d

All three are good; they optimize for different things.

  • minikube is the most complete local experience: upstream Kubernetes, an addon catalog (ingress, metrics-server, registry), multiple drivers and container runtimes, and selectable Kubernetes versions. Best for learning, day-to-day development, and reproducing production behavior locally.
  • kind (Kubernetes-in-Docker) was built to test Kubernetes itself. Clusters are defined in a small YAML file, start fast, and are trivially disposable — which is why it dominates CI/CD pipelines that need to spin up a cluster per test run against multiple Kubernetes versions. Fewer conveniences: no addon system, and ingress or a load balancer is on you.
  • k3d runs k3s — the lightweight, CNCF-certified distribution — in Docker. It's the fastest to start and the lightest on RAM, ships a built-in load balancer, and is the natural choice if your edge or production environment already runs k3s.

Rule of thumb: developing and learning, take minikube; throwaway clusters in CI, take kind; k3s parity or a weak laptop, take k3d.

Conclusion

A local cluster is a superb development tool and a poor production rehearsal — it won't surface the load balancer quirks, IAM boundaries, or upgrade pain that a real environment does. When you're ready for that step, our notes on Kubernetes in real life cover what changes, and our DevOps team helps teams design the path from minikube start to a production-grade cluster.

Tags: #Kubernetes #DevOps #Docker #LocalDev