Minikube can use several "drivers" to spin up a Kubernetes cluster locally, and understanding how they differ is key to picking the right one for your workflow.
Let’s see Minikube in action, specifically focusing on how it manages the underlying virtualization. Imagine you’ve just installed Minikube and want to start a cluster with the Docker driver:
minikube start --driver=docker
This command tells Minikube to leverage your existing Docker daemon to create and manage the Kubernetes node. What’s happening under the hood is that Minikube is essentially creating a Docker container that acts as your Kubernetes control plane and worker node. This container is managed by your local Docker engine.
Now, let’s contrast that with using the HyperKit driver on macOS:
minikube start --driver=hyperkit
Here, Minikube doesn’t rely on a pre-existing container runtime like Docker. Instead, it uses HyperKit, a lightweight macOS-native hypervisor, to create a virtual machine. Inside this VM, Minikube then installs and runs the Kubernetes components. This means you’re not just running a container; you’re running an entire lightweight operating system environment dedicated to your Kubernetes cluster.
The VirtualBox driver offers a similar experience to HyperKit but is cross-platform and generally more feature-rich, though often heavier:
minikube start --driver=virtualbox
Similar to HyperKit, Minikube will provision a full virtual machine using VirtualBox, and then install Kubernetes within that VM. This gives you a more isolated environment, akin to a dedicated server, but with the overhead of managing a full-fledged VM.
The core problem all these drivers solve is providing a self-contained Kubernetes environment on your local machine without needing to interact with a remote cloud provider. They abstract away the complexities of setting up kubeadm or other cluster bootstrapping tools, offering a simple minikube start command.
Internally, each driver translates the minikube start command into a series of operations specific to its underlying technology. For the Docker driver, this involves creating a Docker container with specific network configurations, mounting necessary volumes, and running the Kubernetes binaries within it. For HyperKit and VirtualBox, it involves creating a VM definition, allocating resources (CPU, RAM, disk), booting the VM, configuring its network to be accessible from your host, and then installing and configuring Kubernetes inside that VM.
The exact levers you control are primarily through the minikube start command and subsequent minikube commands. For example, when using the Docker driver, you can influence the container’s resources:
minikube start --driver=docker --cpus=4 --memory=8192mb
This tells Minikube to create the Kubernetes node container with 4 CPU cores and 8GB of RAM, directly impacting the performance of your local cluster. The same --cpus and --memory flags work for HyperKit and VirtualBox, but they are translated into VM resource allocations.
When using the Docker driver, Minikube mounts the Docker socket into the Kubernetes node container. This allows the Kubernetes cluster running inside that container to interact with your host’s Docker daemon for actions like pulling images, which is why docker pull commands run on your host might appear as if they are being run by the Kubernetes node.
The most surprising thing about the Docker driver is that it doesn’t actually run Kubernetes in Docker in the way you might initially imagine. Instead, Minikube spins up a Docker container that contains a full Linux OS and all the necessary Kubernetes components (etcd, API server, controller manager, scheduler, kubelet, kube-proxy, and a container runtime like containerd). This container is your Kubernetes cluster’s node.
The next concept you’ll likely explore is how to manage add-ons within your Minikube cluster, such as the Kubernetes Dashboard or ingress controllers.