# kind — Run Local Kubernetes Clusters in Docker

> Spin up full multi-node Kubernetes clusters inside Docker containers in seconds. kind is SIG Testing's tool — the same way Kubernetes itself runs conformance tests.

## Install

Save as a script file and run:

# kind — Kubernetes IN Docker

## Quick Use
```bash
# install on macOS / Linux
brew install kind            # or: go install sigs.k8s.io/kind@latest

# create a cluster in under a minute
kind create cluster --name dev

# multi-node cluster from a config file
cat <<EOF | kind create cluster --name ha --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker
EOF

kubectl get nodes
kind delete cluster --name dev
```

## 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/


---
Source: https://tokrepo.com/en/workflows/25e04457-3900-11f1-9bc6-00163e2b0d79
Author: Script Depot