kind (Kubernetes in Docker)

kind runs a full Kubernetes cluster on your laptop by turning ordinary Docker containers into Kubernetes nodes — one container is the control plane, more containers are workers, and kubeadm bootstraps each one exactly as it would a real machine. It was built by Kubernetes SIG Testing to run the project's own upstream conformance suite without needing cloud credentials or real hardware, and that origin still shows: a fresh multi-node cluster comes up in under a minute, and tearing it down leaves nothing behind but a stopped container. Today it's the default way most engineers get a disposable, close-to-real cluster for local development, and it's just as commonly the cluster CI pipelines create fresh on every run to execute a Helm chart, an integration test, or a policy check against real API objects instead of a mock. It is not a production runtime, and it doesn't try to be — knowing exactly where that line sits is most of what this page is about.

What kind actually is, and why kubeadm is underneath it

☺ Like you're 10: Each container pretends to be a whole separate computer, and the same setup script real machines use — kubeadm — is what turns each pretend computer into a real Kubernetes node.

A kind "node" is a single Docker container running a specially built image, kindest/node, that carries a systemd init process, a container runtime (containerd), and the Kubernetes binaries for one specific version — the image tag is the Kubernetes version, e.g. kindest/node:v1.31.0. On cluster creation, kind picks one container to be the control-plane node and runs kubeadm inside it exactly the way you'd run it on bare metal, then runs kubeadm join inside each worker container to attach it. This is the detail that makes kind trustworthy rather than a toy: nothing about the API server, the scheduler, or kube-proxy is faked or reimplemented — you're running the genuine upstream control plane described in Kubernetes Architecture, just with node isolation coming from Docker's namespaces and cgroups instead of separate physical or virtual machines.

All of a kind cluster's containers sit on one Docker bridge network and can reach each other by container name, which is also how a control-plane container reaches a worker to schedule a Pod onto it. Docker Desktop, Docker Engine on Linux, and (experimentally, via KIND_EXPERIMENTAL_PROVIDER=podman) Podman can all host a kind cluster — the only hard requirement is a working container runtime with enough CPU and memory handed to it, since every node you ask for draws from that same pool.

The kind config file: multi-node, custom CNI, ingress

☺ Like you're 10: One YAML file says how many pretend computers you want, which jobs they each do, and which doors on your real computer should open into them.

A one-line kind create cluster gives you a single all-in-one node, fine for a quick smoke test. Everything past that goes in a kind.x-k8s.io/v1alpha4 Cluster config, passed with --config, which is where multi-node topology, a swapped-out CNI, and ingress-ready port mappings all live:

# kind-config.yaml — 1 control plane, 2 workers, custom CNI, ingress ports
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: dev

networking:
  disableDefaultCNI: true          # skip kindnet — you'll install Calico/Cilium yourself
  podSubnet: "10.244.0.0/16"       # must match what your CNI manifest expects
  serviceSubnet: "10.96.0.0/16"

nodes:
  - role: control-plane
    kubeadmConfigPatches:
      - |
        kind: InitConfiguration
        nodeRegistration:
          kubeletExtraArgs:
            node-labels: "ingress-ready=true"
    extraPortMappings:               # host → this node's container, for ingress-nginx
      - containerPort: 80
        hostPort: 80
        protocol: TCP
      - containerPort: 443
        hostPort: 443
        protocol: TCP
  - role: worker
  - role: worker

containerdConfigPatches:             # route a private registry through localhost:5001
  - |-
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."localhost:5001"]
      endpoint = ["http://kind-registry:5000"]

kubeadmConfigPatches and kubeadmConfigPatchesJSON6902 reach straight into the kubeadm InitConfiguration/ClusterConfiguration objects kind generates for you — the same shape you'd hand-write for a real cluster, covered in the kubeadm tool guide. That's how the control-plane node above gets labeled ingress-ready=true: kindnet and the stock config don't know or care about ingress controllers, so the label is how ingress-nginx's kind-specific manifest later finds the right node to schedule onto.

CNI and ingress in a kind cluster

☺ Like you're 10: kind comes with a simple built-in network already working, but you can swap it out for a real one if that's what you're actually testing.

By default every kind cluster ships kindnet, a minimal CNI good enough for Pod-to-Pod connectivity and not much else — no NetworkPolicy enforcement, no BGP, none of the eBPF dataplane features a real deployment might depend on. That's fine for testing a Deployment or a Helm chart, and it's exactly why disableDefaultCNI: true exists: set it, then apply a real CNI manifest — Calico or Cilium — right after cluster creation, matching its expected pod CIDR to your podSubnet. This is the standard way Networking & CNI and Multi-Cluster & Fleet Management both recommend proving out NetworkPolicy behavior or multi-cluster mesh federation without touching a cloud account.

Ingress works the same deliberate way: nothing routes traffic from your laptop into the cluster until you wire it up. The pattern above — one node labeled ingress-ready=true plus extraPortMappings for 80 and 443 on that same node — is exactly what ingress-nginx's official kind deployment manifest expects: it carries a nodeSelector for that label and a toleration for the control-plane taint, so it schedules onto the one node whose container actually has those host ports mapped out. Once that's applied, curl localhost/ on your own machine reaches an Ingress object inside the cluster, no port-forward required.

Day-to-day commands

☺ Like you're 10: A handful of commands cover almost everything: make a cluster, get an image into it, look inside it, throw it away.

The one command that trips people up first: kind clusters don't automatically see images sitting in your local Docker cache the way you might expect, because each node container has its own isolated containerd image store. kind load is how an image gets from your machine into every node's store without going through a registry at all.

# --- create, inspect, and remove clusters ---
$ kind create cluster --config kind-config.yaml    # named "dev" per the config above
$ kind get clusters                                  # every kind cluster on this host
$ kind get nodes --name dev                          # the container name of every node
$ kubectl config get-contexts                        # kind writes/merges "kind-dev" for you
$ kind delete cluster --name dev                      # gone — containers stopped and removed

# --- get a locally built image INTO the cluster, no registry needed ---
$ docker build -t myapp:dev .
$ kind load docker-image myapp:dev --name dev         # pushes into every node's containerd store
$ kind load image-archive myapp.tar --name dev        # same, from a saved tarball (airgapped CI)

# --- look inside a node like it's a real machine ---
$ docker exec -it dev-control-plane crictl ps         # containerd's CLI, not docker ps
$ docker exec -it dev-worker journalctl -u kubelet -f # kubelet's systemd logs, live

# --- capture cluster state before tearing it down ---
$ kind export logs ./kind-logs --name dev             # every component's logs, pre-delete
$ kind export kubeconfig --name dev                    # re-merge if the context ever goes stale

That last habit — kind export logs right before kind delete cluster — is worth building early. Once a cluster is gone its logs are gone with it; there's no "kubectl logs on a container that no longer exists."

Using kind in CI

☺ Like you're 10: Every test run gets its own brand-new cluster, used once, then thrown away — so one run's mess can never leak into the next.

This is where kind earns most of its keep in practice. A CI runner is already an ephemeral, throwaway environment, and a kind cluster fits that model exactly: create it fresh at the start of the job, run real kubectl and Helm commands against a real API server, delete it (or just let the runner get recycled) at the end. No shared cluster means no state from one pull request's test run can contaminate the next one's — the single biggest source of "works on my machine, flakes in CI" that a shared staging cluster tends to accumulate.

# .github/workflows/test.yml — matrix-tested against three Kubernetes minors
jobs:
  e2e:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        k8s-version: ["v1.29.8", "v1.30.4", "v1.31.0"]
    steps:
      - uses: actions/checkout@v4
      - uses: helm/kind-action@v1
        with:
          node_image: kindest/node:${{ matrix.k8s-version }}
          config: ./ci/kind-config.yaml
          cluster_name: ci

      - run: docker build -t myapp:${{ github.sha }} .
      - run: kind load docker-image myapp:${{ github.sha }} --name ci

      - run: helm upgrade --install myapp ./chart
                 --set image.tag=${{ github.sha }} --wait --timeout 90s
      - run: kubectl wait --for=condition=available deploy/myapp --timeout=60s
      - run: ./run-integration-tests.sh

      - if: failure()
        run: kind export logs ./kind-logs --name ci      # the artifact worth uploading on red

Gotchas and limits

☺ Like you're 10: A few things catch almost everyone once: images that "aren't there," storage that vanishes, and a real exam that isn't run this way at all.

Images don't cross the boundary by themselves. Covered above, but worth repeating because it's the single most common first-timer confusion: docker build populates your host's Docker image cache, not any node's containerd store, and a Pod referencing that image with no registry behind it will sit in ImagePullBackOff until you run kind load docker-image. Setting imagePullPolicy: Never or IfNotPresent on the Deployment matters too — the default Always will try to pull from a registry even for an image kind just loaded locally.

Storage doesn't survive the cluster. kind ships a default StorageClass backed by Rancher's local-path-provisioner, which is genuinely useful for testing a StatefulSet's PVC lifecycle end to end — see Storage & CSI — but the actual bytes live inside the node container's own filesystem. kind delete cluster takes every PersistentVolume's data with it; there's no separate disk to reattach to a new cluster.

Resource pressure isn't representative. Every node container draws CPU and memory from the same Docker host pool, so a five-node kind cluster on a laptop with 8 vCPUs doesn't behave like five real machines with 8 vCPUs each — it behaves like one machine's worth of resources, sliced five ways, contending with whatever else is running on your laptop at the time. Don't trust eviction behavior, scheduler pressure, or resource-request tuning you observed on kind to transfer directly to real hardware; Scheduling & Resource Management is explicit about that gap.

It isn't the CKA/CKAD/CKS exam environment. Those exams run against a pre-provisioned remote cluster you reach through a browser-based terminal — you don't build the cluster yourself, and kind isn't installed there. That doesn't make kind a bad way to prepare; the API objects, kubectl behavior, and failure modes you practice against a kind cluster are the genuine upstream Kubernetes ones. It just means "set up a kind cluster" is never itself an exam task. This course's own CKA practice tasks and CKAD practice tasks are written to run on exactly this kind of throwaway cluster.

kind vs. minikube vs. k3d: picking a local cluster tool

☺ Like you're 10: They all give you a practice cluster — they just disagree about what a "node" pretends to be.

All three exist to solve the same problem — a real, standards-conformant Kubernetes API to develop and test against, without a cloud bill — and the honest answer for which to reach for is usually "whichever one your team already standardized on," because the differences are real but narrow.

The practical rule most teams land on: reach for kind when you want the closest thing to real upstream Kubernetes behavior for CI or certification practice, reach for minikube when you want a friendlier single-machine dev experience with common addons a command away, and reach for k3d when startup speed and a tiny footprint matter more than being byte-for-byte identical to a stock control plane. Nothing stops a team from using more than one — kind in CI, minikube on individual laptops — since all three speak the same Kubernetes API underneath.