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?
2. How do you get a locally built image into a kind cluster?
3. Why do pods stay Pending on a resource-starved minikube node?
Flashcards
Question
kind in one line
Click to reveal answer
Answer
Kubernetes nodes as Docker containers — multi-node clusters in seconds, CI-friendly.
Question
minikube addons
Click to reveal answer
Answer
Optional cluster services (ingress, metrics-server, dashboard) toggled with minikube addons enable.
Question
Local image without a registry
Click to reveal answer
Answer
kind load docker-image, or minikube image load / docker-env builds.
Question
Expose LoadBalancer locally
Click to reveal answer
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
Before You Start
- No prerequisites listed.