A successful Deployment creation means Kubernetes accepted the request, not that its Pods are running. A Pod with STATUS Pending has not yet been placed where it can run. Check `kubectl get deploy` for the number of ready replicas, then `kubectl get pods` to see each Pod’s status. section 3.2.3 section 5.1
The scheduler looks for a node that meets a Pod’s resource needs and placement requirements. If it cannot find one, the Pod remains Pending. A brief wait may be enough when the cluster provisions resources dynamically; a Pod that stays Pending needs investigation. section 3.2.3 section 5.1
To investigate a Pod that stays Pending:
- Run `kubectl get pods` to identify it. If the namespace contains many Pods, use a label selector to narrow the list. section 3.2.3
- Run `kubectl describe pod $POD_NAME` and read its scheduling events. Describe the Pod rather than relying on the Deployment: the Deployment can show missing replicas without showing the scheduling error. section 3.2.3 section 8.3.2
- Act on the reported cause. Insufficient CPU points to a resource shortage; an untolerated node taint or unsatisfied affinity rule points to a placement mismatch. For a taint, add a suitable toleration or nodes without that taint; for affinity, review and revise the rules. section 3.2.3 section 8.3.2
Warning FailedScheduling 26s (x2 over 26s) default-scheduler 0/2 nodes are available: 2 Insufficient cpu.
This FailedScheduling event reports that neither available node has sufficient CPU, giving a concrete reason for Pending status. section 3.2.3
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 4s default-scheduler 0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate.
This event shows a different cause: the available node has a taint the Pod does not tolerate. section 8.3.2
