Skip to content
beginner Phase 2 · Cluster Setup & Management

Local Clusters: Minikube & Kind

Set up local Kubernetes development environments using Minikube and Kind.

45m
0 problems
Topic Progress 0%

Why Run Kubernetes Locally

Why Run Kubernetes Locally

A laptop cluster lets you rehearse scheduling, RBAC, and rollouts without a cloud bill. Two tools dominate:

  • minikube runs a VM or a container driver with a single-node control plane plus addons — metrics-server, ingress, dashboard — toggled with minikube addons enable.
  • kind (Kubernetes IN Docker) runs each node as a Docker container. Multiple nodes are cheap and disposable, which makes kind the default for testing DaemonSets, topology spread, and upgrades in CI.

Both are CNCF projects running the real apiserver, scheduler, and kubelet — not mocks — so manifests and controllers behave as they will in production, limited mainly by the laptop's CPU and memory.

Creating and Feeding a Cluster

Creating and Feeding a Cluster

cat <<EOF | kind create cluster --name demo --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker
EOF

kind load docker-image myapp:dev --name demo
kubectl get nodes

The load command injects a locally built image straight into each node's containerd, skipping any registry. The minikube equivalents are minikube start --driver=docker, eval $(minikube docker-env) so builds land in the cluster daemon, then minikube image load myapp:dev.

Tear everything down with kind delete cluster --name demo or minikube delete.

Local Cluster Pitfalls

Local Cluster Pitfalls

Pitfall 1 — stale images. Nodes resolve tags they have seen before; if your build reuses myapp:dev, the node keeps the old layers. Always kind load docker-image after rebuilding or bump the tag.

Pitfall 2 — resources and ingress. A node container sharing 4–6 GiB leaves pods Pending when requests sum higher; check kubectl describe node for allocatable versus requests. For external access, minikube needs minikube tunnel to obtain a LoadBalancer IP on Linux/macOS, while kind requires the ingress addon plus extra port mappings on the control-plane container.

Interview-ready: justify kind for multi-node CI testing, explain how images enter without a registry, and describe an upgrade drill you would run locally first.

Quiz

1. What does kind create for each cluster node?

Question 1 options

2. How do you get a locally built image into a kind cluster?

Question 2 options

3. Why do pods stay Pending on a resource-starved minikube node?

Question 3 options

Flashcards

Question

kind in one line

Answer

Kubernetes nodes as Docker containers — multi-node clusters in seconds, CI-friendly.

Question

minikube addons

Answer

Optional cluster services (ingress, metrics-server, dashboard) toggled with minikube addons enable.

Question

Local image without a registry

Answer

kind load docker-image, or minikube image load / docker-env builds.

Question

Expose LoadBalancer locally

Answer

minikube tunnel (Linux/macOS); kind needs ingress addon and extra port mappings.

Revision Notes

Key Takeaways

  • 1. Local clusters run real control planes with laptop-scale limits
  • 2. kind suits multi-node and CI; minikube suits single-node addons
  • 3. Image freshness and request sizing cause most local failures

Interview Tips

  • • Say which tool you use for which job and why (multi-node vs addons)
  • • Describe how CI spins up a cluster, loads images, and applies manifests

Cheat Sheet

kind = nodes as containers (kind load docker-image); minikube = single node + addons; both run real apiserver/kubelet; size requests to laptop resources.

Continue Learning