Minikube’s "none" driver lets you run Kubernetes directly on your host OS, bypassing the need for a separate VM.
Let’s see it in action. First, we need to install Minikube and kubectl. If you’re on macOS, you might use Homebrew:
brew install minikube kubectl
On Linux:
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install kubectl /usr/local/bin/kubectl
Now, start Minikube with the none driver. This command will likely require sudo privileges because it needs to bind to privileged ports and manage network interfaces directly on your host.
sudo minikube start --driver=none
Minikube will then proceed to download necessary Kubernetes components and set them up directly on your machine. You’ll see output indicating the download and configuration process. Once it’s done, you can verify your cluster is running:
kubectl cluster-info
This should show you the Kubernetes control plane and CoreDNS addresses. You can also check your nodes:
kubectl get nodes
You should see a single node, minikube, with a status of Ready.
The "none" driver is particularly useful for development and testing scenarios where you want a quick, lightweight Kubernetes environment without the overhead of a full VM. It’s also a great way to understand Kubernetes networking at a fundamental level, as it exposes the cluster’s components directly to your host’s network stack.
Here’s how it works internally. When you use the none driver, Minikube doesn’t spin up a virtual machine like VirtualBox or Docker. Instead, it uses your host’s operating system and its existing network configuration. It installs the Kubernetes control plane components (API server, etcd, controller-manager, scheduler) and a kubelet directly onto your host. For networking, it typically uses host-local networking or CNI plugins that are designed to run directly on the host. This means pods will often get IP addresses from your host’s network range, and services will be exposed directly on your host’s IP.
The primary advantage is speed and resource efficiency. Starting a cluster with none is significantly faster than with VM-based drivers because there’s no VM to boot. It also consumes fewer resources, as it doesn’t have the overhead of a hypervisor and a separate guest OS. This makes it ideal for machines with limited RAM or CPU.
The "none" driver bypasses the isolation that a VM provides. This means that any network configurations or changes you make to your host’s network can directly affect your Minikube cluster, and vice-versa. It also implies that running multiple Minikube clusters with the none driver simultaneously is not possible, as they would conflict over host resources and network ports.
A common pitfall when using the none driver is related to network configuration, especially if your host uses a VPN or has complex network routing. Because Minikube is directly interacting with your host’s network, conflicts can arise. For instance, if your VPN assigns an IP range that overlaps with the default pod or service CIDRs Minikube might try to use, you’ll run into connectivity issues. In such cases, you might need to explicitly configure the pod and service CIDRs during minikube start to avoid these overlaps. For example:
sudo minikube start --driver=none --pod-network-cidr=10.244.0.0/16 --service-cidr=10.96.0.0/12
This explicitly tells Kubernetes to use these specific IP ranges for pods and services, which can help prevent conflicts with your existing network setup.
The next step after getting your cluster running is usually to deploy an application and understand how its networking is exposed.