Begin with the Pod events
Pending is a phase, not a diagnosis. The Pod may be waiting for scheduling or for a container to be set up. Inspect the exact namespace, Pod and recent events:
kubectl describe pod POD_NAME -n NAMESPACE
Use the output to identify whether the scheduler found a suitable node, a volume could be attached, or an image could be pulled. Events can expire, so correlate with cluster monitoring and workload changes.
Compare requests and constraints
If scheduling fails, compare CPU and memory requests with node allocatable resources and existing reservations. Check taints and tolerations, node selectors, affinity, topology constraints and quotas. A cluster can have unused aggregate capacity but no single node that satisfies all requirements.
For storage, inspect the persistent volume claim and storage class. Placement and volume binding requirements can interact. If the Pod is assigned to a node but still Pending, inspect image-pull and init-container status rather than treating it as a scheduler problem.
Make a measured correction
Do not remove placement or security constraints without understanding why they exist. Validate the workload's requests against measured needs, check capacity and review any intended topology or availability requirements.
After a change, confirm the Pod schedules, starts and becomes Ready, then test the service path. Monitor other workloads for resource pressure and record the original event and the correction.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.