# kind delete cluster: Tear Down and Clean Up

> kind delete cluster removes a kind cluster and its kubeconfig context. Reference for --name, --all, and cleaning up leftover clusters in CI.

Source: https://latchkey.dev/learn/command-reference/kind-delete-cluster  
Updated: 2026-06-30

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
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

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

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt