# kubectl uncordon: Usage, Options & Common CI Errors

> kubectl uncordon makes a previously cordoned node schedulable again. The forgotten-uncordon trap that strands pods Pending after maintenance in CI.

Source: https://latchkey.dev/learn/command-reference/kubectl-uncordon  
Updated: 2026-06-25

Make a node schedulable again after maintenance or a drain.

kubectl uncordon clears the unschedulable flag on a node so the scheduler can place new pods there again. It is the essential cleanup step after a cordon or drain, and the one automation most often forgets.

## What it does

kubectl uncordon NODE sets spec.unschedulable=false, reversing a cordon (or the cordon that drain applied). Existing pods are unaffected - uncordon only re-enables future scheduling. It is idempotent: uncordoning an already-schedulable node is a harmless no-op.

## Common usage

```Terminal
kubectl drain ip-10-0-1-5 --ignore-daemonsets
# ... node maintenance ...
kubectl uncordon ip-10-0-1-5
kubectl get nodes                       # SchedulingDisabled should be gone
```

## Common errors in CI

The classic automation bug is a forgotten uncordon: a maintenance job cordons or drains a node, the uncordon step fails or is skipped, and new pods pile up Pending with "0/N nodes are available: N node(s) were unschedulable". Always run uncordon in a trap/finally so it executes even when the maintenance step errors. Because uncordon is idempotent, re-running it in a retried pipeline is safe. If pods stay Pending after uncordon, the node may still carry a taint (uncordon does not remove taints) - check kubectl describe node.

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

### kubectl uncordon: Usage, Options & Common CI Errors?

kubectl uncordon clears the unschedulable flag on a node so the scheduler can place new pods there again. It is the essential cleanup step after a cordon or drain, and the one automation most often forgets.

### What it does?

kubectl uncordon NODE sets spec.unschedulable=false, reversing a cordon (or the cordon that drain applied). Existing pods are unaffected - uncordon only re-enables future scheduling. It is idempotent: uncordoning an already-schedulable node is a harmless no-op.

### Common errors in CI?

The classic automation bug is a forgotten uncordon: a maintenance job cordons or drains a node, the uncordon step fails or is skipped, and new pods pile up Pending with "0/N nodes are available: N node(s) were unschedulable". Always run uncordon in a trap/finally so it executes even when the maintenance step errors.

---

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