Chapter 5 of a local-Kubernetes series: the payoff chapter where you spin up an actual cluster. k3d gives you a real Kubernetes API, not an emulation, and it's so cheap to create and destroy that recreating from scratch is routine.
Key takeaways
- k3s vs k3d: k3s is a certified, minimalist Kubernetes distro (whole control plane in one binary); k3d is a "lightweight wrapper to run k3s in Docker." Nodes are Docker containers.
- Why it's fast: k3s defaults to embedded SQLite instead of etcd — no etcd cluster to stand up, so fast start and low memory. (Multiple server nodes auto-switch to embedded etcd.)
- The one command to keep:
k3d cluster create dev \
--servers 1 --agents 2 \
--registry-create k3d-registry.localhost:5000 \
-p "8081:80@loadbalancer"
Built-in registry (the fix for chapter 1's ImagePullBackOff-from-local-Docker) + a forwarded port, in one line.
-
Context gotcha: k3d names the context
k3d-dev, notdev. Alwayskubectl config current-contextbefore anything destructive. -
Registry naming: k3d prepends
k3d-, sok3d registry create registry.localhostis referenced ask3d-registry.localhost:5000in--registry-useand inimage:fields. Push from host vialocalhost:5000. -
Port-forwarding via serverlb with
@loadbalancer(k3s ships Traefik) — but port forwards are fixed at creation time; to add one you recreate the cluster (cheap in k3d). - Honest "when to use kind or minikube instead": kind for strict upstream parity / conformance; minikube for learning + addons + VM isolation.
Top comments (0)