Local Kubernetes is a cluster on a developer machine (kind, k3d, minikube, Docker Desktop). Use it to exercise manifests, operators, and “does this Deployment even start,” not to clone production. This site’s host is not your laptop cluster.
kind vs k3d vs minikube
- kind: Kubernetes-in-Docker, CI-friendly, node images are containers. Good default for “test the YAML.”
- k3d: wraps k3s, fast, less memory. Fine for local apps.
- minikube: older, still fine; VM or docker driver.
Pick one per team so docs match. All of them are not EKS/AKS/GKE: no real multi-AZ, no cloud LB unless you fake it, different storage classes.
Workflow
kind create cluster --name dev
kubectl apply -k ./deploy/local
kubectl -n app port-forward deploy/api 8080:8080
Build images into the cluster’s docker (kind load, k3d import). Pointing a local cluster at image: myapp:latest on Docker Hub will surprise you with an old public tag.
What breaks it
image: myapp:latest is not in the kind nodes, so the pod pulls an old public tag or stays in ImagePullBackOff. Load the tag you built, and use that same tag in the Deployment.
kind load docker-image myapp:dev --name devimage: myapp:devPitfalls
- Treating local as prod-like (real TLS, real IAM, real sizes).
- Leaving clusters running until Docker eats the laptop.
- Committing kubeconfigs with user certs.
Ingress/LB on local: Local Kubernetes with Load Balancer.