kind: Kubernetes Clusters as Docker Containers, Reviewed for Local Testing

What kind Solves, and Who It Is Actually For

kind runs local Kubernetes clusters by making each node a Docker container. The README is explicit about the audience: kind "was primarily designed for testing Kubernetes itself, but may be used for local development or CI." That ordering matters. The project lives under kubernetes-sigs, the Kubernetes special interest group structure,. Its center of gravity is the Kubernetes test and release workflow, not the individual developer's daily environment. The problem it removes is the setup cost of a real cluster. Instead of provisioning machines or VMs, you pull a node image and start containers. The README's own summary is one line: with Go and Docker, Podman or nerdctl installed, `go install sigs.k8s.io/[email protected] && kind create cluster` is the whole path. The project also supports multi-node clusters, including HA, and can build Kubernetes release builds from source using make or bash or Docker. That last capability is the clearest signal of who it is for: people who need to run a Kubernetes build they just produced, not just a published release.

How kind Bootstraps Nodes with kubeadm

Each node is a container built from a kind node image. The README states that kind "bootstraps each 'node' with kubeadm," and points to the design documentation for detail. That single sentence explains most of the behavior you will observe. kubeadm is the standard Kubernetes cluster bootstrapping tool, so the resulting cluster is not a trimmed-down simulation; it is a real control plane and real kubelets running inside containers. The repository layout reflects the same split. The Go packages under pkg/ implement cluster creation and image build, the kind CLI in main.go is a thin command layer over those packages, and the images/ directory holds the Docker images written to run systemd and Kubernetes. So the flow is: the CLI reads your config, starts containers from a node image, and kubeadm inside those containers forms the cluster. Because nodes are containers, the cluster's lifetime is tied to the container runtime. Docker, Podman and nerdctl are all named as supported runtimes, which is useful if your environment is not Docker-based. The README also notes kubetest integration built on the same packages, marked WIP, which reinforces that the packages are the product and the CLI is one consumer of them.

Installing kind and Creating a First Cluster

The README gives several install paths and recommends stable binaries for CI usage in particular. The Go route is the shortest if you already have a Go toolchain. The README warns to use the latest Go, and points at .go-version for the exact version the project builds with; the binary lands in $(go env GOPATH)/bin.

go install sigs.k8s.io/[email protected]

If that directory is not on your PATH you will see `kind: command not found`, and the README suggests adding it or building manually with `make build` from a cloned repository. Without Go installed, the README says kind can be built reproducibly with Docker using `make build`. On macOS, Homebrew and MacPorts are both listed. On Linux, the release assets are downloaded by platform, made executable, and moved into place.

[ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.33.0/kind-$(uname)-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

With a container runtime running, creating a cluster is one command. The README shows this as the basic usage, and deleting it is the matching inverse.

kind create cluster
kind delete cluster

Multi-node clusters and other advanced features are configured with a config file; the README points to the user guide and to `kind [command] --help` for the rest. For a cluster built from Kubernetes source, the README requires the source to be cloned at `$(go env GOPATH)/src/k8s.io/kubernetes`, then two commands: `kind build node-image` followed by `kind create cluster --image kindest/node:latest`.

Where kind Is the Wrong Tool

The container-as-node design has a boundary, and it is worth stating plainly. If your container runtime stops or is restarted, the nodes are containers, so the cluster is not a durable artifact the way a VM-backed cluster is. Treat any kind cluster as disposable. The README does not document rollback or upgrade procedures for existing clusters; it documents creation and deletion, and the release notes are the place to look for version changes. A second limitation is the dependency chain. kind needs Docker, Podman or nerdctl, and it needs the node image to be pullable. In an environment where containers are not permitted, kind is simply unavailable, regardless of how well it would otherwise fit. Third, the project is honest about its maturity: the README carries a note that "kind is still a work in progress" and links a 1.0 roadmap. That is not a reason to avoid it, but it does mean you should pin a version rather than track main, especially in CI. Finally, if your goal is a long-lived development cluster with persistent volumes that survive reboots and no container runtime in the loop, kind's model is the opposite of what you want.

kind Versus minikube: Container Nodes Versus Drivers

The README does not compare kind with minikube, so this section sticks to what kind documents about its own model. Nodes are always containers, and kind supports multi-node clusters, including HA. That makes kind a fit when the cluster's shape is part of what you are testing, for example control plane behavior across several nodes. kind also supports building Kubernetes release builds from source, and the README documents a node-image build path for exactly that, so it is a natural choice when you need to run a Kubernetes build you just produced. The practical question is whether a container runtime (Docker, Podman or nerdctl) is a resource you have and are willing to make the cluster depend on.

Maintenance, Releases and the Apache-2.0 Licence

The repository is not archived, and the last push was on 2026-10-29. Releases are not frequent: v0.33.0 arrived on 2026-08-26, v0.32.0 on 2026-06-02, and v0.31.0 on 2025-12-18. That cadence is consistent with a project whose consumers pin versions, and the README's advice to use stable releases for CI points the same way. Plan to test a new kind release against your workload before moving CI onto it. The licence is Apache-2.0, the same licence the Kubernetes project uses, which is permissive and includes an explicit patent grant; the repository ships the full text in LICENSE. If you redistribute kind or a node image built from it, read the licence and the NOTICE conventions yourself rather than assuming a summary is sufficient. Nothing here is legal advice. The Go module path is sigs.k8s.io/kind, so dependency pinning follows normal Go module semantics. Note that go.mod declares `go 1.17` as the minimum language version while .go-version records the compiler used for builds, a distinction the file comments on directly.

Editorial conclusion

Adopt kind if you need a disposable, multi-node Kubernetes cluster that starts from a single command and can be built from Kubernetes source, and if Docker, Podman or nerdctl is already part of your workflow. Do not adopt it if you need a cluster that outlives a container runtime restart, or if you want a long-running development cluster with persistent storage and no Docker dependency. Before committing, verify that your container runtime is installed and running, check which kind release matches the Kubernetes version you need, and confirm you can reach the release assets or the Go module proxy from your network.

Frequently asked questions

Official sources

1. kubernetes-sigs/kind on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases