Skip to main content
In this lab you will diagnose a Pending Pod caused by a missing scheduler and manually schedule it onto a specific node using nodeName. This exercise demonstrates how Kubernetes schedules Pods, what happens when the scheduler is not available, and how to place a Pod on a chosen node manually. Objective: create a Pod from nginx.yaml and manually schedule it onto specific nodes when the kube-scheduler is not available.

​
Initial environment and Pod creation

Environment summary:
  • Cluster with two nodes (controlplane and node01).
  • A file named nginx.yaml defines a simple Pod using the nginx image.
  • We’ll create the Pod and observe its status.
Check nodes and list files:
Contents of nginx.yaml (initial version):
Create the Pod:

​
Check Pod status

Immediately after creation the Pod appears in Pending state:

​
Why is the Pod Pending?

A Pending Pod typically means it has not been scheduled to any node. Inspecting the Pod shows Node: <none> and there are no scheduling events:
Check core control-plane Pods in the kube-system namespace:
Because the scheduler Pod (kube-scheduler) is not present, no automated scheduling occurs and the Pod remains in the Pending state.

​
Manually scheduling the Pod

You can bypass the kube-scheduler by setting nodeName in the Pod spec. This pins the Pod to the named node during creation. Edit nginx.yaml and add nodeName: node01 under spec:
Apply the change by replacing the existing Pod. kubectl replace --force -f deletes and recreates the resource:
Monitor the Pod as it is being created (it typically moves from ContainerCreating to Running):
Verify which node the Pod landed on using wide output:
You cannot move a running Pod from one node to another directly. To “move” a Pod, delete the Pod on its current node and recreate it with a different nodeName (or let the kube-scheduler place it). Pods are host-bound until recreated elsewhere.
Deleting a Pod includes a graceful termination period: Kubernetes sends termination signals to the container and waits for shutdown. This can take a few seconds and is expected behavior.

​
Scheduling the Pod on the control-plane node

For practice, set nodeName: controlplane in nginx.yaml and repeat the replace step. This forces the Pod onto the control-plane node even if the scheduler would not place regular workloads there. Important: control-plane nodes often include taints (for example, node-role.kubernetes.io/master:NoSchedule) that prevent regular workloads from being scheduled. Manually setting nodeName bypasses the scheduler, but NoExecute taints can still evict a Pod unless it has matching tolerations. Example replace & watch commands:

​
Quick command reference

This completes the manual scheduling exercise: create a Pod, diagnose Pending status due to a missing scheduler, and manually schedule it using nodeName.

Watch Video