kind delete cluster stops and removes the Docker containers for the named cluster and deletes its kind- context from kubeconfig. kind get clusters lists what exists, and kind delete clusters --all removes them all.

kind delete cluster: Tear Down and Clean Up

By Daniel Zoghalchali·Latchkey

kind delete cluster --name <name> removes the cluster containers and its kubeconfig context; kind delete clusters --all wipes every kind cluster.

Ephemeral means torn down. Deleting the cluster frees the runner and, critically, stops a leftover cluster from colliding with the next job by name.

What it does

kind delete cluster stops and removes the Docker containers for the named cluster and deletes its kind-<name> context from kubeconfig. kind get clusters lists what exists, and kind delete clusters --all removes them all.

Common usage

Terminal

kind delete cluster --name ci
kind get clusters                 # what is still around
kind delete clusters --all        # nuke everything kind created

Options

Form	What it does
delete cluster --name <n>	Delete one cluster
delete clusters --all	Delete every kind cluster
get clusters	List existing kind clusters
--kubeconfig	Operate on a non-default kubeconfig

In CI

Put deletion in an always-run cleanup step (a trap, or if: always() in a workflow) so a failed test still tears the cluster down. On self-hosted runners that reuse the machine, leftover clusters cause node(s) already exist on the next create, so cleanup is not optional.

Common errors in CI

unknown cluster "ci" (a warning) just means there was nothing to delete; it is safe to ignore in cleanup. If containers persist after delete, the Docker daemon may have been mid-restart; rerun kind delete clusters --all. A read-only mounted kubeconfig can leave a stale context behind even after the containers are gone.

Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

Terminal

# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes

Frequently asked questions

kind delete cluster: Tear Down and Clean Up?

Ephemeral means torn down. Deleting the cluster frees the runner and, critically, stops a leftover cluster from colliding with the next job by name.

What it does?

kind delete cluster stops and removes the Docker containers for the named cluster and deletes its kind-<name> context from kubeconfig. kind get clusters lists what exists, and kind delete clusters --all removes them all.

In CI?

Put deletion in an always-run cleanup step (a trap, or if: always() in a workflow) so a failed test still tears the cluster down. On self-hosted runners that reuse the machine, leftover clusters cause node(s) already exist on the next create, so cleanup is not optional.

Common errors in CI?

unknown cluster "ci" (a warning) just means there was nothing to delete; it is safe to ignore in cleanup. If containers persist after delete, the Docker daemon may have been mid-restart; rerun kind delete clusters --all. A read-only mounted kubeconfig can leave a stale context behind even after the containers are gone.

References

GitHub Actions documentation