kubectl uncordon: Usage, Options & Common CI Errors
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
kubectl drain ip-10-0-1-5 --ignore-daemonsets
# ... node maintenance ...
kubectl uncordon ip-10-0-1-5
kubectl get nodes # SchedulingDisabled should be goneCommon 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.
# 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