minikube

What it does

minikube starts a single-node Kubernetes cluster on a local machine, giving developers a real control plane and API server without a cloud subscription. On Windows it installs as a signed executable and can create its cluster inside a container runtime, a Hyper-V virtual machine, or another supported driver. The resulting environment behaves like a production cluster for the purposes that matter during development: kubectl connects normally, manifests apply identically, custom resources and operators can be installed, and images built locally can be loaded into the cluster's runtime without a registry round trip. Add-on commands enable ingress controllers, metrics servers, dashboards and storage provisioners with a single flag.

The workflow

The typical sequence is to install a driver first, then create the cluster, then point kubectl at the generated context. minikube manages its own kubeconfig entries, so switching between local clusters and remote ones is a context change. Day-to-day use involves building an image locally, loading it into the cluster, applying manifests, and following logs or port-forwarding a service to the host. The integrated dashboard and tunnel commands expose services without external configuration, and the cluster can be paused, stopped and restarted without losing workloads stored in the persistent volume directory.

Practical settings and limits

Resource allocation is explicit: the default profile claims a fixed share of CPU, memory and disk, and everything the cluster stores lives in a profile directory under the user profile, which grows over time. On Windows, the driver choice matters - the container driver is the lightest, Hyper-V requires the relevant Windows feature and can conflict with other hypervisors, and the Docker driver inherits Docker Desktop's own licensing and networking behaviour. Nested virtualisation, corporate proxies and endpoint security agents are the usual causes of a cluster that will not start. The tool targets one node, so it cannot reproduce multi-node scheduling, real network policies or production-scale storage.

Who should choose something else

kind is leaner for CI pipelines and ephemeral clusters, Rancher Desktop bundles a similar single-node cluster with a desktop interface, and Podman Desktop covers container work with an optional Kubernetes provider. For anything resembling production topology - multiple nodes, real ingress, managed storage - a small cloud cluster or a lab hypervisor environment is a better investment than stretching a local tool past its design.