kind

Kubernetes IN Docker: each cluster node is a container, so a conformant multi-node cluster starts and disappears inside a CI job.

What it is: Container orchestration
Part of: Local Kubernetes
Type: Open source
Made by: Kubernetes project (SIG Testing)
License: Apache 2.0
Facts checked: 6 October 2026

What it is

kind (Kubernetes IN Docker) treats containers as machines. kind create cluster starts one container per Kubernetes node from a prebuilt “node image” that holds systemd, containerd, the kubelet and the other Kubernetes binaries. Inside each node container, kubeadm bootstraps the node as it would on a real server, and your Pods run as containers nested inside it, started by that node’s own containerd. A short config file asks for extra workers or three control-plane nodes, all on one host. kind keeps no state of its own: a cluster is just the set of containers carrying its label, so deleting the cluster deletes those containers. Docker is the default engine, with Podman and nerdctl also supported; on macOS and Windows the engine itself runs in a Linux VM such as Docker Desktop’s.

It was built in Kubernetes’ SIG Testing to test Kubernetes itself, and its docs call end-to-end test automation “the original & primary use case”; local development and CI for your own apps come second. The features follow from that: kind build node-image turns a Kubernetes source tree or release into a node image, kind load docker-image copies an image you just built into the nodes without a registry, and each release lists node images pinned by digest. Unlike minikube there are no VM drivers to choose, and unlike K3s or MicroK8s nothing is meant to outlive the test: kind is a CNCF-certified conformant installer, not a production distribution, and it is still pre-1.0 (v0.33 in August 2026).

Why teams pick it

Needs only a container engine, so a cluster fits on a CI runner and is created and deleted in one job
Multi-node and highly available control planes on one machine, each node a container you can docker exec into
Builds node images from Kubernetes source or any release, so you can test Kubernetes changes before they ship
Clusters are built by upstream kubeadm and pass the conformance tests, so tests exercise the real components

Watch out for

Not for production or long-lived clusters; the project lists node reboots, upgrades and persistent volumes among the things it can’t yet test well
With Docker Desktop on macOS or Windows the nodes sit inside a VM, so their IPs aren’t reachable from the host without port mappings or a proxy
LoadBalancer Services need Cloud Provider KIND, a separate binary on the host with privileges to open ports and drive the container engine
Podman and nerdctl run rootless by default and need extra setup, and the node image’s internals are unsupported and may change in any release

More of the Kubernetes family

What all container orchestration have in common →

minikubeOpen sourceFor local developmentA local Kubernetes cluster for developers on Linux, macOS or Windows, in a container, a VM or on the host itself, with laptop-friendly extras.

Amazon EKSAWSManaged servicesAWS runs the Kubernetes control plane for you; you choose how much of the worker side to hand over too.

Azure Kubernetes ServiceAzureManaged servicesMicrosoft’s managed Kubernetes: a control plane that can be free, node pools of Azure VMs, and an Automatic mode that runs the nodes too.

Google Kubernetes EngineGoogle CloudManaged servicesGoogle’s managed Kubernetes, the oldest one: Google runs the control plane, and in Autopilot mode the nodes too.

K3sOpen sourceDistributionsA certified Kubernetes distribution in one small binary, built for edge, IoT and other places where a full cluster is too heavy, with SQLite or embedded etcd for state.

MicroK8sOpen sourceDistributionsCanonical’s Kubernetes in one snap package: installs with one command on Linux, forms a highly available cluster by itself at three nodes, and adds features as addons.

Red Hat OpenShiftCommercialDistributionsRed Hat’s Kubernetes platform: Kubernetes plus its own OS, operators that install and upgrade everything, and stricter security defaults, sold by subscription.

RKE2Open sourceDistributionsSUSE’s security-focused Kubernetes distribution: one binary per node, hardened defaults, FIPS-validated crypto and close alignment with upstream.

Talos LinuxOpen sourceDistributionsA Linux distribution that only runs Kubernetes: immutable, minimal, with no shell or SSH, and managed entirely through an API.

kubeadmOpen sourceToolsThe official tool for turning Linux machines you already have into a Kubernetes cluster: `kubeadm init`, then `kubeadm join`.

RancherOpen sourceToolsSUSE’s open-source control plane for fleets of Kubernetes clusters: one place to create, import, secure and upgrade them.

AgonesOpen sourceBuilt on itRuns dedicated multiplayer game servers on Kubernetes: keeps a fleet of them warm, hands one to each match, and never kills a server while players are on it.

KlutchOpen sourceBuilt on itA young open-source control plane, built on Crossplane, that lets many application clusters order databases from one central Kubernetes cluster.

How it fits with other technologies

What kind uses

A three-node test cluster, an image loaded without a registry, then cleanup · bash

cat > kind.yaml <<'EOF'
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker
EOF
kind create cluster --name test --config kind.yaml --wait 5m
kind get nodes --name test          # each node is a container

docker build -t my-app:ci .
kind load docker-image my-app:ci --name test
kubectl --context kind-test apply -f deploy.yaml

kind delete cluster --name test     # removes the node containers

See it in a real stack

No architecture uses kind yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2018–2026

Some Kubernetes tests need real clusters in a cloud, with a cloud provider attached. The SIG Testing design for kind argued that enough of them could run locally to justify something much cheaper: clusters “that any developer can locally replicate”, integrated with the project’s test tooling, thoroughly documented, “very stable” and able to pass all conformance tests. Each “node” would be a Docker container that boots into a paused state, so the tooling can fix mounts and preload images before it starts systemd and runs kubeadm.

The first release, v0.0.1, came out in November 2018 and v0.1.0 in January 2019. kind is a SIG Testing subproject led by Benjamin Elder and Antonio Ojea of Google. Its scope document ranks the goals: testing Kubernetes itself first, then testing applications built on Kubernetes (cert-manager and Cluster API providers were named stakeholders), then cheap bootstrap clusters for Cluster API. Replacing Docker Compose is explicitly out of scope.

Later releases widened where it runs. Rootless Docker, Podman and nerdctl became supported node providers in v0.11 (2021), and Cloud Provider KIND, presented at KubeCon EU 2024, gives LoadBalancer Services a real address by starting a load-balancer container for each one.

Why it’s built this way

Containers as nodes: A container starts far faster than a VM and runs anywhere a container engine does, including CI machines. Running systemd and containerd inside each node container keeps it close to a real node, and kubectl sees ordinary nodes.
Reuse kubeadm and upstream libraries: Its principles say not to reinvent the wheel: kubeadm handles node configuration and certificates, kustomize merges user patches into the generated kubeadm config, and k8s.io libraries supply the config machinery. Clusters are therefore built the same way many real ones are.
No external state: State lives in the node containers as labels, files and processes, and kind itself stores nothing. That keeps it portable, and deleting a cluster that doesn’t exist is deliberately not an error, so cleanup scripts can always run it.
Built for automation, degrade gracefully: Because it is used for testing, a partly working cluster is better than a failure: images packed into the node image are preloaded, and if that fails the node’s runtime pulls them instead.

Timeline

2018
SIG Testing design for containers as nodes; v0.0.1 in November
2019
v0.1.0 in January; KubeCon EU talks on testing with kind
2021
v0.11 supports rootless Docker, Podman and nerdctl
2024
Cloud Provider KIND brings LoadBalancer Services (KubeCon EU)
2026
v0.33 in August defaults to Kubernetes 1.37

Sources11 · facts checked 6 October 2026

Improve this page on GitHub