Minikube, the tool for running Kubernetes locally, has a surprisingly flexible upgrade path that lets you jump multiple versions at once, not just incremental steps.
Let’s see it in action. Imagine you have an older Minikube cluster running Kubernetes 1.25 and you want to get to the latest stable release, say 1.29. You don’t have to upgrade to 1.26, then 1.27, and so on. You can go straight to 1.29.
First, check your current version:
minikube version
This will output something like:
minikube version: v1.32.0 on Ubuntu 22.04
Kubernetes version: v1.25.16
Now, to upgrade to the latest stable Kubernetes version, you simply specify it using the --kubernetes-version flag with the minikube start command. Minikube will detect that a cluster already exists and prompt you to delete and recreate it, or it can handle the upgrade process. The start command, when a cluster exists, will attempt to upgrade.
To upgrade to Kubernetes 1.29.0 (replace with the actual latest stable version you want):
minikube start --kubernetes-version v1.29.0
Minikube will then:
- Stop the existing Minikube VM/container.
- Re-provision the VM/container with the new Kubernetes version.
- Install the new Kubernetes components (kubelet, kube-apiserver, etc.).
- Re-apply your existing Minikube configurations (like add-ons).
This process preserves your existing Minikube configuration, including any add-ons you’ve enabled, and your persistent volumes. However, all workloads running inside the cluster will be lost because the Kubernetes control plane and nodes are effectively rebuilt.
The problem Minikube’s upgrade process solves is the friction of keeping local development environments up-to-date with the rapidly evolving Kubernetes ecosystem. Instead of a complex, multi-step manual process of tearing down and rebuilding, Minikube offers a single command to transition to a newer Kubernetes version. Internally, minikube start --kubernetes-version triggers a workflow where the existing cluster’s VM or container is destroyed, and a new one is provisioned with the specified Kubernetes binaries. This is why existing deployments are lost. It’s a fresh Kubernetes installation within your existing Minikube environment.
The exact levers you control are primarily the target Kubernetes version and the driver Minikube uses (e.g., Docker, VirtualBox, KVM). You can also specify other flags like --cpus, --memory, and --disk-size to adjust the resources allocated to your Minikube VM during the start operation, which can be beneficial after an upgrade if you find your cluster needs more resources.
You can also explicitly delete and start fresh if you encounter issues or want to ensure a completely clean slate:
minikube delete
minikube start --kubernetes-version v1.29.0
This guarantees no remnants of the old Kubernetes version interfere with the new setup.
It’s important to note that while Minikube attempts to preserve add-ons, complex configurations or add-ons that have specific version dependencies might require manual re-installation or re-configuration after the upgrade. Always check the release notes for the Kubernetes versions you are upgrading between for any breaking changes or deprecations that might affect your workloads or add-ons.
The next challenge you’ll likely face after a successful upgrade is ensuring your deployed applications are compatible with the new Kubernetes version, especially if there were significant changes in API versions or feature gates.