Minikube - Local Kubernetes for Developers

If you've been running Docker containers and think you're ready for Kubernetes, here's some bad news: you're not. Kubernetes is a different beast entirely. Minikube exists to bridge that gap by running a complete Kubernetes cluster on your laptop.

What Runs Inside That VM

When you run minikube start, it spins up a VM (or container) with the entire Kubernetes control plane. This isn't just Docker - it's a full orchestration system with multiple components working together: the API server, etcd, scheduler, and controller manager.

When you run minikube start, it spins up a VM with the full control plane. Not just Docker - the whole orchestration system.

Why Teams Actually Use Minikube

Learning Without Breaking Things

The Kubernetes documentation recommends Minikube as the starting point because it gives you a real cluster to experiment with. You can break deployments, crash services, and mess up networking without affecting anyone else. I've seen developers go from Docker Compose to production Kubernetes in a few weeks using Minikube to understand the concepts.

Reasonable Resource Usage

Minikube officially needs 2GB RAM and 2 CPUs, but that's optimistic. In practice, you want 4GB+ unless you enjoy watching pods take forever to start. Still, it's way lighter than running a multi-node cluster on your laptop.

CI/CD Testing

Most CI platforms support Minikube because it's cheaper than spinning up real clusters for every test run. I've worked on projects where our integration tests ran against Minikube - it's close enough to real Kubernetes for most scenarios.

Predictable Failures

Unlike some local K8s tools, when Minikube breaks, it usually breaks in documented ways. There's a GitHub issue for almost every error you'll encounter, which beats debugging mysterious failures in production.

Resource Reality Check

The docs say 2GB RAM and 2 CPUs. That'll work but you'll hate life. On a 2GB machine, I've sat there for forever waiting for it to start.

What you actually need:

• 4+ CPUs - Less than this and everything takes forever
• 4-8GB RAM - Tried 2GB once, pods kept getting killed
• 30GB+ disk space - Images pile up fast

They say you can run 100+ pods. Sure, if your definition of "running" is pretty loose. Gets slow around 20 pods doing real work.

Common Ways Minikube Breaks

VirtualBox dies every macOS update. Ventura broke VirtualBox 6.x for months. Spent a whole Friday trying to demo something, turns out Tuesday's update killed the kernel extensions again.

Docker driver randomly stops working. Trying to show a coworker something, minikube start just sits there. Docker Desktop updated overnight and disabled WSL2 integration. Wasted hours on that.

Forgetting minikube tunnel. Deploy a LoadBalancer service, everything looks good, spend forever debugging networking. Then realize tunnel isn't running. Every damn time.

Running out of space mid-demo. "No space left on device" while people are watching your screen. Docker images filled up the default 20GB. Now I run docker system prune regularly.

Recent versions get flaky after a few days if you leave them running. Think it's CoreDNS memory leak but not totally sure. Just restart minikube when kubectl starts timing out.

The troubleshooting guide is actually pretty good - bookmark it because you'll need it.

Driver Options and Reality

Minikube supports multiple drivers, and each has different trade-offs. After running this across different teams and environments, here's what you need to know:

Container Drivers:

• Docker - Best choice if you already have Docker installed. Fast startup, good performance. Can be unstable on Windows.
• Podman - Rootless alternative to Docker. More secure but networking can be tricky, especially on macOS.

VM Drivers:

• VirtualBox - Slow but predictable. When other drivers fail, VirtualBox usually works.
• VMware - Fast and reliable if you have VMware Fusion or Workstation installed.
• Hyper-V - Windows only, requires admin rights, networking setup is complex.
• KVM - Linux only, excellent performance once libvirt permissions are sorted out.

Start with Docker driver. If that gives you trouble, VirtualBox is your reliable fallback.

Addons That Actually Help

The addon system is one of Minikube's best features. One minikube addons enable command gets you functionality that would take hours to configure manually.

Essential addons:

Dashboard - Web UI for browsing your cluster. Actually useful for debugging when kubectl gets tedious.

Ingress - NGINX ingress controller. Essential if you want to expose services properly instead of using NodePort.

Metrics Server - Enables kubectl top and horizontal pod autoscaling. Required for any performance monitoring.

Useful for specific needs:

Registry - Local Docker registry at localhost:5000. Handy for development, though you'll forget the port number constantly.

Registry Creds - Automatically configures credentials for AWS ECR, GCP Container Registry. Saves you from ImagePullBackOff errors.

Skip unless you have specific needs:

Istio - Service mesh is serious overkill for a single-node development cluster.

EFK Stack - Elasticsearch will consume all your RAM. Use it only if you're specifically testing logging setups.

Dashboard and Ingress are the most commonly used because they solve immediate development needs.

Networking Basics

Kubernetes networking takes some getting used to, and Minikube has its own quirks:

Service Types

ClusterIP - Internal cluster access only. This works reliably and is perfect for backend services.

NodePort - Exposes services on high-numbered ports (30000+). Use minikube ip to get the cluster IP, then access your service at that IP plus the NodePort.

LoadBalancer - This is where it gets tricky. LoadBalancer services need minikube tunnel running to get external IPs.

The minikube tunnel Command

This command creates network routes so LoadBalancer services get real IP addresses instead of staying "pending" forever.

The catch is it needs sudo privileges on Linux and macOS, so you'll get prompted for your password. You need to keep this running in a separate terminal while you're using LoadBalancer services.

If you forget to run tunnel and wonder why your service isn't accessible, that's usually the problem. On Windows, tunnel can be inconsistent - NodePort is often more reliable there.

Storage Limitations

Persistent volumes in Minikube use hostPath storage, which has some important implications:

• Data survives pod restarts and recreations
• Data gets wiped when you run minikube delete
• No real backup or replication - it's just files on the host
• Fine for development, don't rely on it for anything important

Storage classes exist but they all use the same underlying hostPath mechanism, so the class you choose doesn't affect durability or performance.

Development Workflow: The Actually Useful Stuff

Image Development Loop:

## The old way (slow)
docker build -t myapp .
docker push myregistry/myapp
kubectl set image deployment/myapp myapp=myregistry/myapp

## The Minikube way (fast)
eval $(minikube docker-env)
docker build -t myapp .
kubectl set image deployment/myapp myapp=myapp:latest

This minikube docker-env thing is useful - builds images right in the cluster.

Port Forwarding That Actually Works:

## Quick access to services
minikube service myservice --url

## Traditional kubectl still works
kubectl port-forward svc/myservice 8080:80

Registry Addon for Local Images:

minikube addons enable registry
## Registry available at localhost:5000
## Push/pull like any other registry

Performance Reality Check

They say you can run 100+ pods. Sure, if your definition of "running" is "using RAM and doing nothing."

Real performance:

• Driver matters: Docker > VMware > VirtualBox
• Need RAM: 8GB minimum, 16GB to stay sane
• Workload type: 20 nginx pods ≠ 20 Postgres pods

Started getting slow around 15-20 pods with real workloads. By the time we hit 25 or so, kubectl commands started timing out.

We tried running like 40 microservices for integration tests once. Build times went from maybe 10 minutes to forever. Switched to Kind and it was way faster, though I don't remember the exact times.

Bottom line: Minikube is great for learning and development, terrible for load testing. Use k6 or JMeter against real clusters for performance work.