Manual Scheduling in Kubernetes

 In Kubernetes, the scheduler acts as the cluster’s strategist, deciding the optimal Node for every Pod. While the default scheduler is automated and highly efficient, there are scenarios where you might want to take direct control over Pod placement.

---

The Automated Scheduler

For most workloads, the default Kubernetes scheduler handles Pod placement. It uses a two-stage process—filtering and scoring—to find the most suitable Node for each Pod.

Stage 1: Filtering

In this stage, the scheduler identifies Nodes that can feasibly run the Pod by applying a series of checks called predicates. Nodes failing any check are excluded from consideration.

Common filters include:

• PodFitsResources: Ensures the Node has enough CPU and memory for the Pod.

• PodFitsHostPorts: Verifies if the requested port is available on the Node.

• NodeSelector: Matches Node labels with the Pod’s nodeSelector field.

• Taints and Tolerations: Ensures the Pod can tolerate any taints on the Node.

If no Node passes the filtering stage, the Pod remains in a Pending state until a suitable Node becomes available.

Stage 2: Scoring

After filtering, multiple feasible Nodes may remain. The scheduler ranks these Nodes using priority functions to select the best fit.

Common scoring rules include:

• LeastRequestedPriority: Prefers Nodes with lower resource utilization to balance workloads.

• ImageLocalityPriority: Gives preference to Nodes that already have the container image, reducing startup time.

• NodeAffinity / Anti-Affinity: Attracts or repels Pods based on Node labels.

• PodAffinity / Anti-Affinity: Places Pods relative to other Pods running on Nodes.

The Node with the highest score is selected, and the Pod is bound to it.

---

Manual Scheduling with nodeName

If you want to bypass the scheduler entirely, Kubernetes allows you to specify a Node manually using the nodeName field in the Pod specification. This instructs Kubernetes to place the Pod on a specific Node without running the scheduling logic.

Steps to Manually Schedule a Pod

Step 1: Create a Cluster Config
Define a configuration file specifying the number of worker nodes.

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker

Step 2: Create the Cluster

kind create cluster --config config.yml

Step 3: Verify Cluster Nodes

kubectl get nodes

Step 4: Create a Pod YAML with nodeName
Specify the Node on which the Pod should run.

apiVersion: v1
kind: Pod
metadata: 
  name: my-pod
  labels:
    run: my-pod
spec:
  nodeName: kind-control-plane
  containers:
  - name: my-pod
    image: nginx
  restartPolicy: Never

Step 5: Apply the Pod Configuration

kubectl apply -f pod.yml

Step 6: Confirm Pod Placement

kubectl get pods -o wide

The Pod will appear on the Node specified in nodeName. You can repeat this process to schedule Pods on different Nodes manually.

---

Why Running Pods Can’t Be Moved

In Kubernetes, a Pod’s Node assignment is immutable. Once scheduled—whether automatically or manually—the Pod cannot be moved to another Node.

To “move” a Pod to a different Node:

1. Use a Controller: Ensure Pods are managed by a Deployment, StatefulSet, or similar.

2. Delete the Pod: The controller notices the replica count is below the desired number.

3. Recreate the Pod: A new Pod is created and scheduled according to the scheduler’s rules, possibly on a different Node.

This approach reinforces Kubernetes’ design principle: Pods are ephemeral, replaceable units, not permanent machines.