Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Pending means Kubernetes accepted a Pod, but at least one container is not yet set up and ready. The Pod may still be waiting for a node, or it may already be assigned to one while image download or another startup task is in progress. Start by checking the Pod’s Events and container state; the word Pending alone does not identify the cause.
What does Pending mean in Kubernetes?
Kubernetes defines the Pod phase this way: “The Pod has been accepted by the Kubernetes cluster, but one or more of the containers has not been set up and made ready to run.” See the Kubernetes Pod Lifecycle documentation.
Pending is a broad lifecycle phase, not a diagnosis. It includes time before scheduling as well as time spent on setup such as downloading an image. The STATUS column shown by kubectl is intended as a user-friendly summary; it is not a complete account of Pod state. A container in the Waiting state may be undergoing startup work, such as pulling an image or applying Secret data.
What should I check first?
Identify the exact Pod and namespace, then inspect its details and recent Events before changing requests, scaling the workload, or adding cluster capacity. Kubernetes’ Pod debugging guide recommends beginning with the Pod’s current state and events.
#1 Best Overall
-
Confirm the Pod’s name and namespace:
kubectl get pod <pod-name> -n <namespace> -
Inspect its conditions, container states, and Events:
kubectl describe pod <pod-name> -n <namespace> -
In the Events section, note the
Reason, message, and reporting component. Also check whether the Pod has a node assignment and whether a container isWaiting. -
If you need more object detail, inspect the Pod manifest:
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.kubectl get pod <pod-name> -n <namespace> -o yaml
The key split is whether the scheduler has assigned a node. No node assignment plus a FailedScheduling event points to a scheduling constraint. An assigned node with a container in Waiting points to setup on that node, which can include an image pull.
Rank #2
How do I diagnose FailedScheduling?
Read the scheduler’s event message as a report of constraints, then compare those constraints with the Pod specification and the cluster’s eligible nodes. Do not assume low current CPU or memory use means a Pod can fit: scheduling evaluates requests against available node resources.
Insufficient CPU or memory
An event such as 0/N nodes available: insufficient cpu directs attention to resource requests and node capacity. Compare the Pod’s requests with node allocatable resources and resources already allocated to Pods. The Kubernetes documentation explains resource management for containers and recommends kubectl describe nodes to review capacity and allocated resources.
Depending on what that comparison shows, options may include freeing capacity by terminating unneeded Pods, adding nodes, or correcting a request that exceeds what any node can satisfy. Reduce or otherwise adjust a request only if it accurately reflects what the workload needs.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Taints, tolerations, selectors, and affinity
A taint can exclude a node unless the Pod has a matching toleration. A node selector, affinity rule, or other placement requirement can also leave no eligible nodes. If the event cites a taint or placement mismatch, inspect the Pod’s placement settings and the nodes’ labels and taints. The Pod debugging guide includes a selector matching no nodes as a possible scheduling failure; Kubernetes’ taints and tolerations guidance explains how taints affect placement.
Host-port conflicts
A hostPort requirement constrains which nodes can run a Pod, and a conflict can prevent placement. Check whether the workload really needs a host port. For common cases where the goal is to expose a Pod, Kubernetes’ debugging guide suggests using a Service instead.
Storage and volume topology
For a Pod using storage, inspect the relevant PersistentVolumeClaim (PVC), StorageClass, events, and CSI driver behavior. Some combinations have scheduling implications: for example, with a WaitForFirstConsumer StorageClass, a CSI driver that advertises storage-capacity support can provide capacity information that the scheduler uses along with topology to consider eligible nodes.
This behavior depends on the StorageClass and installed CSI driver; it is not a universal property of PVCs. Capacity information can be outdated, prompting scheduling retries, and certain combinations of multiple volumes and topology can require manual intervention. Consult the Kubernetes storage-capacity documentation alongside the documentation for your driver.
Free tools Windows power users keep installed
One-click scans. No signup required.
Scheduling gates
A Pod can be intentionally held back from scheduling by .spec.schedulingGates. If events do not show an ordinary scheduling attempt, inspect the Pod’s gates. The gates are set when the Pod is created and can later be removed, but new gates cannot be added after creation. Kubernetes’ Pod Scheduling Readiness documentation marks the feature stable since Kubernetes v1.30 and shows SchedulingGated as a status. Check documentation that matches your cluster version when applying version-dependent guidance.
What if a node is assigned but the Pod is still Pending?
When a node is assigned and a container is Waiting, look at the container’s reason and Events rather than treating the issue as a scheduler rejection. Image pulling is one common setup stage that keeps a Pod in the Pending phase.
Check the image and registry access
-
Verify the image name and tag in the Pod specification.
-
Confirm that the image was pushed to the registry from which the cluster is pulling.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Use the reported pull reason to investigate the specific failure; check registry access or credentials if the event points to them.
The Kubernetes debugging guide recommends checking the image name and whether it was published. If the Events identify a different startup operation, investigate that operation rather than making scheduling changes.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What should I change once I know the cause?
Make a change only when the observed event and Pod configuration support it. Apply lasting changes to the owning workload or its manifest where appropriate, rather than patching a single managed Pod and expecting the change to persist.
| Evidence | Next inspection | Possible response |
|---|---|---|
FailedScheduling cites insufficient CPU or memory |
Compare requests with node allocatable and already allocated resources. | Free capacity, add nodes if appropriate, or correct an unjustified request. |
| Event cites taints, selectors, or placement rules | Compare Pod tolerations, selectors, and affinity with node taints and labels. | Correct the mismatch to reflect the workload’s intended placement. |
| Storage or topology-related event | Inspect the PVC, StorageClass, CSI events, and driver-specific behavior. | Address the identified provisioning or topology issue; do not assume all PVCs behave alike. |
| Pod is gated from scheduling | Inspect .spec.schedulingGates and identify the workflow responsible for the gate. |
Coordinate removal of the intended gate with its controller or admission workflow. |
| Assigned node; container is waiting on an image | Check the image reference, registry publication, access, and the reported pull reason. | Correct the image or the specific registry access or credentials problem identified. |
Deleting a Pod is not a general fix. An individual Pod is not rescheduled to another node; a higher-level controller may create a replacement, but that replacement can hit the same constraint. See the Pod lifecycle documentation for how Pods and replacement Pods behave.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
