Minikube with the KVM2 driver lets you run a single-node Kubernetes cluster directly on your Linux KVM hypervisor, bypassing the need for a separate VM management tool.
Let’s see it in action. Imagine you’ve got KVM set up and virt-manager is your daily driver for VMs. You want to test a Kubernetes deployment locally without the overhead of Docker Desktop or kind.
First, ensure you have KVM and libvirt installed and running. On most Debian/Ubuntu systems, this means:
sudo apt update
sudo apt install qemu-kvm libvirt-clients bridge-utils virtinst libvirt-daemon-system
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt $(whoami)
You’ll need to log out and back in for the group change to take effect.
Next, install Minikube. The easiest way is often via a release binary:
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube
rm minikube-linux-amd64
Now, you can start your Minikube cluster using the kvm2 driver:
minikube start --driver=kvm2
This command will:
- Download a suitable KVM image if one isn’t already present.
- Create a new KVM virtual machine using
virt-installandvirt-builder. - Configure networking for the VM, often using
virt-manager’s default NAT network or a custom bridge if you’ve set one up. - Boot the VM and install Kubernetes components inside it.
- Configure
kubectlon your host machine to point to this new Minikube cluster.
After a few minutes, you should have a running Kubernetes cluster. You can verify this:
kubectl get nodes
Output will look something like:
NAME STATUS ROLES AGE VERSION
minikube Ready control-plane 5m v1.28.3
The core problem Minikube solves is providing a quick, isolated Kubernetes environment for development and testing on a Linux workstation. It abstracts away the complexities of setting up a full multi-node cluster or managing VM configurations manually. The kvm2 driver specifically leverages the native Linux virtualization capabilities, which can offer better performance and resource utilization compared to container-based drivers for certain workloads, especially when your host machine is already running KVM.
Internally, minikube start --driver=kvm2 orchestrates several libvirt commands. It uses virt-builder to fetch a base OS image (like Ubuntu) and then virt-install to create a new VM based on that image. It configures the VM with necessary resources (CPU, memory, disk) and sets up networking. Once the VM is up, Minikube SSHes into it to download and install Kubernetes components (kubeadm, kubelet, kubectl, container runtime) and then runs kubeadm init to bootstrap the control plane. Finally, it sets up kubectl on your host to communicate with the API server running inside the Minikube VM.
The most surprising thing is how seamlessly Minikube can integrate with your existing libvirt network configurations. If you’ve already set up a custom bridge interface (e.g., br0) for your KVM VMs to have IPs on your physical network, Minikube can be instructed to use it. This allows your Minikube cluster’s pods to be directly reachable from other machines on your LAN, which is invaluable for testing network-aware applications or ingress controllers that need external access. You can achieve this by passing network configuration arguments during minikube start, though it’s often simpler to let Minikube create its default network and then reconfigure it later if needed, or to use minikube network create --driver=kvm2 --subnet=192.168.100.0/24 --gateway=192.168.100.1 before starting.
After getting your cluster running and deploying a simple Nginx pod, the next hurdle you’ll likely encounter is exposing that pod to the outside world using Service objects of type NodePort or LoadBalancer, and understanding how Minikube’s networking translates those services to your host.