How to Fix a Kubernetes Pod Stuck in Pending

Why pods get stuck in Pending

When you create a Deployment or Pod, the scheduler tries to place it on a node. If no node satisfies all of the pod's constraints - nodeSelector, affinity rules, taints, or resource requests - the scheduler skips it silently. The pod stays in Pending indefinitely and no log message tells you why.

The rejection reason is in the Events section of kubectl describe pod, not in kubectl get pods. That's where to start every time.

Step 1: confirm the pod is Pending and read the Events

kubectl get pods
# NAME                   READY   STATUS    RESTARTS   AGE
# web-7d9f5b8c4-xk2qp    0/1     Pending   0          3m

kubectl describe pod -l app=web

Scroll to the Events section at the bottom of the output. The scheduler logs a line for every node it rejected:

Events:
  Warning  FailedScheduling  3m  default-scheduler
           0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector.

This tells you the pod has a nodeSelector or affinity rule that no node satisfies.

Step 2: check what labels the nodes actually have

kubectl get nodes --show-labels

Compare the output to the nodeSelector in your Deployment manifest:

spec:
  template:
    spec:
      nodeSelector:
        disktype: ssd     # <- no node has this label

If no node carries disktype=ssd, the pod can never be placed. Either remove the selector entirely or change it to a label that actually exists on a node.

Step 3: fix the manifest and re-apply

Remove (or correct) the impossible selector, then apply:

spec:
  template:
    spec:
      # nodeSelector removed - pod can now land on any node
      containers:
        - name: web
          image: nginx:stable

kubectl apply -f deployment.yaml
kubectl rollout status deployment/web

Within seconds the scheduler places the pod and rollout status completes.

Other common Pending causes

The Events section names every root cause - the fix follows from what it says:

• Taints without tolerations - a node is tainted key=value:NoSchedule but the pod has no matching tolerations: block. Add one or remove the taint.
• Resource requests too large - requests.memory: 64Gi on a 16 Gi node. Lower the request or add a bigger node.
• PVC not bound - the pod mounts a PersistentVolumeClaim that's still Pending. Fix the PVC first; the pod schedules once it binds.
• Too-strict anti-affinity - requiredDuringSchedulingIgnoredDuringExecution rules that can't be satisfied given how many nodes you have.

In every case the Events message is specific. Reading it first saves the guesswork.