# kind: Run Local Kubernetes Clusters Using Docker for Testing

> kind (Kubernetes IN Docker) is a tool for running local Kubernetes clusters where each node is a Docker container. It was built primarily for testing Kubernetes itself and is a CNCF certified conformant Kubernetes installer, also used for local development and CI pipelines.

**kubernetes-sigs/kind** — Kubernetes IN Docker - local clusters for testing Kubernetes

- Repository: https://github.com/kubernetes-sigs/kind
- Website: https://kind.sigs.k8s.io/
- Stars: 15,523 · Forks: 1,809
- Language: Go
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/kubernetes-sigs-kind

## What kind Is and Who Builds It

kind stands for Kubernetes IN Docker. The README describes it as a tool for running local Kubernetes clusters using Docker container nodes. It was primarily designed for testing Kubernetes itself, but the README acknowledges it may also be used for local development or CI.

kind is a Kubernetes SIG project. SIG stands for Special Interest Group, which is the governance structure the Kubernetes project uses to organize contributors around specific domains. kind lives under kubernetes-sigs, the GitHub organization for Kubernetes SIG projects. The project is a CNCF certified conformant Kubernetes installer, meaning clusters it creates pass the Kubernetes conformance test suite.

The tool consists of four components: Go packages implementing cluster creation and image building, a command-line interface built on those packages, Docker images written to run systemd and Kubernetes, and integration with the kubetest testing harness. The README notes that the kubetest integration is a work in progress. Each kind node container bootstraps Kubernetes using kubeadm.

## Installing kind and Creating Your First Cluster

kind can be installed from a pre-built binary, via a package manager, or by building from source with Go. The README provides platform-specific instructions.

On macOS via Homebrew:

```console
brew install kind
```

On Linux (AMD64):

```console
[ $(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
```

On Windows via Chocolatey:

```powershell
choco install kind
```

Once kind is installed and Docker is running, create a cluster:

```console
kind create cluster
```

To delete the cluster:

```console
kind delete cluster
```

For Go users, the README also provides a one-liner: `go install sigs.k8s.io/kind@v0.33.0`. This places the kind binary in `$(go env GOPATH)/bin`. The README notes to use the latest stable Go version and references the `.go-version` file in the repository for the exact version used in CI.

## How kind Bootstraps a Cluster

Each kind cluster node is a Docker container running systemd and Kubernetes components. The node images are purpose-built Docker images maintained in the `images/` directory of the repository. They are distinct from the Kubernetes container images used in production clusters: they are designed to run the full Kubernetes control plane and kubelet inside a container rather than on a host OS.

kind uses kubeadm to initialize each node. The README references the design document at `kind.sigs.k8s.io/docs/design/initial` for the architectural details. The cluster creation process involves: starting the node containers, running kubeadm init on the control plane node, and running kubeadm join on worker nodes. kubeconfig is written to the host machine for kubectl access.

kind supports Docker, podman, and nerdctl as container runtimes. The README's quick-start states that any of these three can be used in place of Docker. This matters for environments where Docker Desktop is not available, such as some Linux CI hosts where nerdctl or podman may be preferred.

## Multi-Node Clusters and Building from Kubernetes Source

The default kind create cluster creates a single-node cluster with one control plane node. Multi-node clusters and other advanced configurations require a YAML config file passed with the `--config` flag. The README references the user guide at `kind.sigs.k8s.io/docs/user/quick-start` for these configurations.

kind supports multi-node clusters including high-availability configurations. The README lists multi-node (including HA) cluster support as a named capability.

For Kubernetes contributors, kind supports building clusters from Kubernetes source. The workflow requires the Kubernetes repository cloned at `$(go env GOPATH)/src/k8s.io/kubernetes`. Build a node image and create the cluster:

```console
kind build node-image
kind create cluster --image kindest/node:latest
```

This capability makes kind the standard tool for testing changes to Kubernetes itself before they are merged. The node image build process compiles the Kubernetes components from source and packages them into the node container image.

## Limitations and Cases Where kind Is the Wrong Tool

kind requires a container runtime: Docker, podman, or nerdctl must be installed and running. There is no path to run kind without one. In environments where container runtimes are not available or are restricted by security policy, kind is not an option.

kind is not designed for production workloads. The README describes it explicitly as a tool for testing Kubernetes and notes that it is still a work in progress with a 1.0 roadmap. Node containers are not equivalent to full virtual machines or real servers, and some Kubernetes features that depend on specific kernel modules or hardware may behave differently inside Docker containers.

kind clusters are ephemeral by design. State stored in the cluster is lost when the cluster is deleted. Persistent volumes backed by host paths inside Docker containers are also subject to container lifecycle. Teams that need persistent development environments across machine restarts should look at tools that manage VM-based nodes.

The go.mod file specifies `go 1.17` as the minimum language version for the module, though the build itself requires a newer Go toolchain as documented in `.go-version`. Users building kind from source need to verify the Go version requirement.

## Comparison with minikube

minikube is the other widely used tool for local Kubernetes clusters. The README does not compare kind to minikube directly, but the architectural difference is well-established: minikube typically runs Kubernetes in a virtual machine (though it also supports Docker and container runtime drivers), while kind runs every node as a Docker container.

The container-based approach makes kind faster to start than a VM-based cluster. The trade-off is that container nodes share the host kernel, which can affect the behavior of tests that exercise kernel features or network namespacing at a deep level. For Kubernetes itself testing, where the goal is to exercise the Kubernetes API and control plane logic, this is generally not a concern.

kind's support for building clusters from Kubernetes source is a differentiator for Kubernetes contributors. minikube can also pull pre-built images but does not have a purpose-built workflow for building from the Kubernetes source tree.

## CI Integration, Supported Versions, and License

kind is used in the Kubernetes project's own CI via kubetest integration. The README recommends using stable releases for CI: stable binaries are available from the GitHub releases page. The current release is v0.33.0, dated 2026-08-26. The last push to the repository was on 2026-09-24.

kind supports Linux, macOS, and Windows. The README lists this explicitly as a named capability. The Makefile sets `CGO_ENABLED=0` and builds a statically linked binary by default, which means the kind binary has no shared library dependencies and can be copied to any compatible system without installing a runtime.

The go.mod dependencies are minimal: cobra for CLI argument parsing, BurntSushi/toml and pelletier/go-toml for configuration files, and evanphx/json-patch for handling Kubernetes API patches. The lean dependency graph makes kind straightforward to vendor and audit.

The license is Apache-2.0, the standard license for Kubernetes ecosystem projects. Commercial use, modification, and redistribution are permitted without disclosure requirements.

## Conclusion

kind is the right tool for Kubernetes developers and CI pipelines that need a real, conformant cluster quickly on a machine that already runs Docker. It supports multi-node and HA cluster topologies, can build clusters from Kubernetes source, and is the reference tool for the Kubernetes project's own test suite. It is not designed for production workloads or for environments without Docker, podman, or nerdctl installed. The README notes that kind is still a work in progress toward the 1.0 roadmap. Before adopting it, verify that your container runtime is supported and that you are prepared to manage kind cluster images for your target Kubernetes version. The license is Apache-2.0.

## FAQ

### What does kind mean in Kubernetes?

kind stands for Kubernetes IN Docker. It is a tool that runs each Kubernetes cluster node as a Docker container rather than as a virtual machine or a full server, making it possible to spin up a complete Kubernetes cluster on a laptop or CI host in seconds.

### Can kind create multi-node Kubernetes clusters?

Yes. kind supports multi-node clusters including high-availability configurations with multiple control plane nodes. Multi-node topologies require a YAML configuration file passed with the --config flag. The default kind create cluster command creates a single control plane node.

### Does kind work with podman or nerdctl instead of Docker?

Yes. The README states that kind works with Docker, podman, or nerdctl as the container runtime. Any of these three can be used in place of Docker.

## Sources

- [kubernetes-sigs/kind on GitHub](https://github.com/kubernetes-sigs/kind)
- [License: Apache-2.0](https://github.com/kubernetes-sigs/kind/blob/main/LICENSE)
- [Project website](https://kind.sigs.k8s.io/)
- [README](https://github.com/kubernetes-sigs/kind/blob/main/README.md)
- [Releases](https://github.com/kubernetes-sigs/kind/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kubernetes-sigs-kind