Introduction

In kind, Kubernetes nodes run as Docker containers, so images used by the cluster live inside those node containers rather than only in your host Docker daemon. That is why docker images on the host does not tell you what the kind cluster can actually run. To inspect loaded images, you need to look inside the node runtime.

Understand the Two Image Locations

There are two separate places you may care about:

• the host machine's Docker image store
• the container runtime inside each kind node

If you build an image locally, it exists on the host first. The kind cluster only sees it after you load it into the node image store or pull it from a registry.

That is the main source of confusion.

List Images Inside a kind Node

Start by identifying the kind node containers.

docker ps --format '{{.Names}}' | rg '^kind-'

Then inspect images inside a specific node. For a default single-node cluster, the control-plane container is often enough.

docker exec -it kind-control-plane crictl images

This lists the images available to the Kubernetes runtime inside that node.

If crictl is unavailable in your environment, ctr is another option:

docker exec -it kind-control-plane ctr -n k8s.io images list

Either command answers the real question better than host-level docker images.

Load a Local Image into kind

If you built an image on the host and want kind to use it, load it explicitly.

kind load docker-image myapp:dev

After that, verify again from inside the node:

docker exec -it kind-control-plane crictl images | rg 'myapp'

This confirms the image is present where Kubernetes actually needs it.

Check What Running Pods Reference

Sometimes you do not need every loaded image. You only need to know what images the cluster is trying to run. In that case, query Kubernetes directly.

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}'

This shows image references from pod specs. It does not prove the image is locally loaded, but it tells you what Kubernetes expects.

Multi-Node Clusters Need Per-Node Inspection

If your kind cluster has multiple worker nodes, an image may exist in one node runtime and not in another. When debugging image availability, inspect every node or load the image in a way that reaches the whole cluster.

This matters especially when a workload is scheduled on a worker and only the control-plane node has the image.

Check the Node That Will Actually Run the Pod

In multi-node kind clusters, the most useful image check is often node-specific rather than cluster-wide. If a workload lands on a worker node that never received the image, Kubernetes can still fail with image pull errors even though another node shows the image locally. Always line up image inspection with real scheduling behavior.

Common Pitfalls

• Checking host docker images and assuming the kind cluster sees the same image list.
• Loading an image into kind and verifying only on the wrong node.
• Forgetting that multi-node clusters may have different image stores per node.
• Assuming a pod uses a local image even though imagePullPolicy forces a remote pull.
• Looking only at pod specs when the real question is whether the image exists in the node runtime.

Summary

• kind nodes have their own container runtime image store.
• Host Docker images and kind node images are related but not the same thing.
• Use docker exec ... crictl images or ctr inside the node to see loaded images.
• Use kind load docker-image to move a local host image into the cluster.
• For multi-node clusters, verify image presence on the nodes that may actually run the pods.