# kubectl describe node: Usage, Options & Common CI Errors

> kubectl describe node shows taints, conditions, allocatable, and pod pressure. Diagnosing unschedulable pods and node pressure in CI clusters.

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

See a node's taints, conditions, capacity, and what it is running.

kubectl describe node prints a node's taints, conditions, allocatable resources, and the requests already committed to it. It is the command that explains why a pod will not schedule or why a node is misbehaving.

## What it does

kubectl describe node NODE aggregates the node's labels and taints, its Conditions (Ready, MemoryPressure, DiskPressure, PIDPressure), Capacity vs Allocatable, the Allocated resources summary (requests/limits as a percentage), and the list of non-terminated pods on it - the full picture of node health and headroom.

## Common usage

```Terminal
kubectl describe node ip-10-0-1-5
kubectl describe node ip-10-0-1-5 | grep -A6 'Allocated resources'
kubectl describe node ip-10-0-1-5 | grep -A3 Taints
kubectl describe node ip-10-0-1-5 | grep -A8 Conditions
```

## Common errors in CI

When pods sit Pending, describe node is where you confirm the cause: a Taints line (e.g. node.kubernetes.io/not-ready or a dedicated taint) the pod does not tolerate, or an Allocated resources block already near 100% so a new request will not fit. MemoryPressure: True / DiskPressure: True conditions explain evictions and a NoSchedule taint the kubelet added automatically. SchedulingDisabled in the node's status means it was cordoned. On managed clusters you may lack RBAC to describe nodes; "nodes \"X\" is forbidden" then means the runner's service account needs the node get/list permission.

## 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 describe node: Usage, Options & Common CI Errors?

kubectl describe node prints a node's taints, conditions, allocatable resources, and the requests already committed to it. It is the command that explains why a pod will not schedule or why a node is misbehaving.

### What it does?

kubectl describe node NODE aggregates the node's labels and taints, its Conditions (Ready, MemoryPressure, DiskPressure, PIDPressure), Capacity vs Allocatable, the Allocated resources summary (requests/limits as a percentage), and the list of non-terminated pods on it - the full picture of node health and headroom.

### Common errors in CI?

When pods sit Pending, describe node is where you confirm the cause: a Taints line (e.g. node.kubernetes.io/not-ready or a dedicated taint) the pod does not tolerate, or an Allocated resources block already near 100% so a new request will not fit.

---

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