A local cluster is a virtual machine, and it keeps every image you pulled

A local Kubernetes cluster is a virtual machine with a container runtime inside it, which means it has all the storage behaviour of both: a virtual disk that grows and does not shrink, and an image store that keeps everything ever pulled.

Where each tool keeps its disk

du -sh ~/.minikube ~/.kube ~/.colima \
  ~/Library/Containers/com.docker.docker/Data 2>/dev/null | sort -h
minikube profile list 2>/dev/null
kind get clusters 2>/dev/null

Clusters you forgot are running

The first thing to check is not size but existence. A cluster created for a tutorial six months ago is still on disk, and depending on the tool it may still be running and consuming memory as well:

minikube delete --all --purge
kind delete cluster --name <name>
colima delete

--purge on minikube also removes the ~/.minikube directory itself, which is the part that holds cached images and ISO downloads. Without it, deleting the cluster leaves several gigabytes behind.

Images inside a cluster you are keeping

minikube ssh -- docker system df
minikube ssh -- docker image prune -a

Images pulled inside the cluster are stored in the cluster's own disk, not in your Docker Desktop images, so pruning on the host does nothing for them. That surprises people who have already cleaned up Docker and seen no change.

Docker Desktop's built in Kubernetes

If you use the Kubernetes that ships with Docker Desktop, everything lives inside the same virtual disk as your containers, so the cleanup is the Docker prune sequence followed by reclaiming the disk file. Turning Kubernetes off in settings when you are not using it also stops it holding images.

The base images and ISOs

Each tool caches the machine image it boots from, typically a few hundred megabytes per version, in its own directory. Upgrading the tool adds a new one, in the same way Playwright keeps a browser per version.