k3d, kind, Helm, Kustomize, Tilt, Skaffold, k9s: a one-screen map of who does what
Drowning in the local-Kubernetes tool zoo? Chapter 3 of the series sorts them onto shelves so you can see that you probably only need two of them. It's reference material, deliberately opinionated-but-fair.
Key takeaways
- Two fundamentally different approaches. (1) Run all of Kubernetes locally (k3d/kind/minikube). (2) Connect your local process to a remote cluster (Telepresence/mirrord/Gefyra). The series takes approach 1.
-
Foundation layer: Docker (local cluster nodes are just Docker containers with Kubernetes inside) + kubectl (the official CLI everything else calls under the hood; it has Kustomize built in via
-k). - Local clusters: k3d (k3s in Docker — fastest start, lowest memory, built-in registry), kind (upstream K8s, CNCF-certified, what the K8s project uses for CI/conformance), minikube (VM/driver + rich addons, great for learning). Consensus for dev: kind or k3d.
- Manifest format: Helm (package manager — charts, templating, releases, rollbacks; ~75% of orgs, Helm 4 shipped Nov 2025) vs Kustomize (template-free base + overlays, built into kubectl). They complement more than compete.
- Inner-loop accelerators: Tilt (Live Update + rich web UI, Tiltfile in Starlark), Skaffold (Google, YAML, CLI), DevSpace (two-way sync, YAML, CLI). Okteto and Garden solve adjacent problems.
- The remote tools differ meaningfully: only Telepresence needs root; Telepresence and mirrord can swap files/env (Gefyra can't); only mirrord handles several local processes at once.
- Helpers: k9s (terminal UI / "visual kubectl", colour-code prod red so you don't nuke it), kubectx/kubens, stern, krew.
- Why the series picks k3d + Tilt: real K8s API + fast/cheap recreate, plus a minutes→seconds loop and a beginner-friendly dashboard. Both OSS and local.
Top comments (0)