You can delete and recreate a Minikube cluster cleanly by first deleting the existing cluster and then starting a new one.
Let’s see this in action. Imagine you’ve been tinkering with Minikube, maybe installed some add-ons that are now causing issues, or you just want a completely fresh start. You’ve probably tried minikube delete and then minikube start before, but sometimes things linger.
Here’s how to make sure it’s really clean:
First, the delete. This command tears down the Minikube virtual machine, its Kubernetes components, and all associated configurations.
minikube delete --all --purge
The --all flag ensures that all Minikube-managed Kubernetes resources (like pods, services, deployments) are removed. The --purge flag is the key here; it goes a step further than a regular delete by removing all Minikube configuration files and caches from your user’s home directory. This means no lingering secrets, no leftover configurations, just a clean slate.
After running that, you might want to do a quick check to ensure Minikube’s configuration directories are gone. On Linux/macOS, this would be ~/.minikube and ~/.kube. On Windows, it’s typically %USERPROFILE%\.minikube and %USERPROFILE%\.kube. If you see them, manually remove them:
# On Linux/macOS
rm -rf ~/.minikube ~/.kube
# On Windows (PowerShell)
Remove-Item -Recurse -Force $env:USERPROFILE\.minikube
Remove-Item -Recurse -Force $env:USERPROFILE\.kube
Now, to bring it back to life, we start a new cluster. You can specify your preferred driver if you have one, otherwise Minikube will pick a default. For example, to start with the Docker driver:
minikube start --driver=docker
This command will provision a new virtual machine, install a fresh Kubernetes control plane and node components, and configure kubectl to point to this new cluster.
The most surprising truth about Minikube’s "clean" state is that the --purge flag, while powerful, doesn’t always remove everything if you’re using specific drivers or have manually modified certain system configurations outside of Minikube’s direct control. For instance, if you’ve ever manually edited /etc/hosts to point minikube.local to your Minikube IP, that entry might persist. Similarly, if you’ve installed kubectl as a system-wide binary rather than letting Minikube manage it, that binary will remain. The minikube delete --all --purge command focuses on the Minikube-specific artifacts and the virtual machine itself, not system-level modifications you might have made.
After minikube start, your kubectl get nodes command should show a single node in a Ready state, and kubectl get pods --all-namespaces should show only a few system pods running.
The next common hurdle after a clean reset is re-applying any custom configurations or add-ons you had previously installed, as they are all gone with the purge.