kind — Run Local Kubernetes Clusters in Docker

Introduction

kind (Kubernetes IN Docker) was built by the Kubernetes SIG Testing group to run the upstream conformance suite inside CI. It turned out to be the fastest way anyone had found to get a real Kubernetes API server running on a laptop, and it quickly became the default local cluster for operator authors, Helm chart maintainers, and anyone who needs to iterate on YAML without burning cloud credits.

What kind Does

• Boots a full Kubernetes control plane inside a single Docker (or Podman) container per node
• Supports multi-node, HA, and IPv6 topologies from a small YAML config
• Preloads container images via kind load docker-image so CI builds never hit a registry
• Runs the same kubeadm flow as production clusters, so behavior matches what ships
• Tears down in seconds, making it ideal for ephemeral test jobs in GitHub Actions

Architecture Overview

Each kind "node" is a Docker container running the kindest/node image, which bundles kubeadm, kubelet, containerd, and a CNI plugin (kindnet by default). The host process talks to the API server on a port forwarded out of the control-plane container, while pod networking lives entirely inside the cluster network namespace. Because nodes are containers, images built on the host can be side-loaded without a registry push.

Self-Hosting & Configuration

• Install via brew, go install, or the release binaries at kind.sigs.k8s.io
• A Cluster resource describes nodes, extraPortMappings, extraMounts, and kubeadm patches
• kind load docker-image and kind load image-archive seed images into every node
• Switch to Calico, Cilium, or any CNI by disabling kindnet and applying manifests post-create
• Multiple clusters can coexist; pick one with --name or kubectl config use-context kind-<name>

Key Features

• Cluster spin-up in ~30 seconds on modern laptops
• Works on Docker Desktop, Colima, Rancher Desktop, and rootless Podman
• Built-in support for kubeadm patches to test alpha API server flags
• First-class CI story: kind is how Kubernetes itself runs its e2e suite
• Extensible node image — rebuild with your own kubelet to test patches

Comparison with Similar Tools

• minikube — older, supports more drivers (VM, bare metal) but slower to start
• k3d — wraps k3s in Docker; lighter runtime, different distribution
• microk8s — snap-based, production-grade, but heavier for ephemeral CI
• Rancher Desktop — GUI + local cluster; great for desktop, not CI
• Docker Desktop Kubernetes — one-click, but single-node and slow to reset

FAQ

Q: Can kind run on Apple Silicon? A: Yes. The node image publishes arm64 variants and Docker Desktop or Colima handle the rest.

Q: How do I expose a Service to the host? A: Add extraPortMappings to the cluster config, or use kubectl port-forward for ad-hoc access.

Q: Does kind support persistent volumes? A: Yes, via a local-path provisioner. For stateful tests, mount a host directory with extraMounts.

Q: Can I use it to test cluster upgrades? A: Yes — pin the node image to a specific Kubernetes version and recreate the cluster with a newer tag.

Sources

• https://github.com/kubernetes-sigs/kind
• https://kind.sigs.k8s.io/