Why scheduling controls Pod placement in Kubernetes - Visual Breakdown

Process Flow - Why scheduling controls Pod placement

Pod Created

↓

Scheduler Watches Pods

↓

Evaluate Node Conditions

↓

Filter Nodes (Resources, Labels)

↓

Score Nodes (Preferences)

↓

Select Best Node

↓

Bind Pod to Node

↓

Pod Runs on Selected Node

The scheduler watches new Pods, filters and scores nodes based on conditions, then assigns the Pod to the best node for running.

Execution Sample

Kubernetes

kubectl apply -f pod.yaml
# Scheduler selects node
kubectl get pods -o wide
# Shows Pod assigned node

Create a Pod, scheduler picks a node, then check where the Pod runs.

Process Table

Step	Action	Evaluation	Result
1	Pod Created	Pod needs placement	Pod enters Pending state
2	Scheduler watches Pod	Pod is unscheduled	Scheduler starts processing
3	Filter nodes	Check node resources and labels	Nodes without enough CPU filtered out
4	Score nodes	Score nodes based on preferences	Node A scores 8, Node B scores 5
5	Select best node	Highest score is Node A	Node A selected
6	Bind Pod to node	Assign Pod to Node A	Pod assigned to Node A
7	Pod runs	Node A starts Pod containers	Pod status Running on Node A
8	Exit	Pod is running	Scheduling complete

💡 Pod is running on the selected node, scheduling process ends

Status Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	Final
Pod State	Pending	Pending	Pending	Pending	Running
Candidate Nodes	All nodes	Filtered nodes (Node A, Node B)	Scored nodes (A=8, B=5)	Selected Node A	Node A
Binding Status	None	None	None	Bound to Node A	Bound to Node A

Key Moments - 3 Insights

Why doesn't the Pod run immediately after creation?

The Pod starts in Pending state (see Step 1 in execution_table) because it needs the scheduler to assign it to a suitable node first.

How does the scheduler decide which node to pick?

The scheduler filters nodes by resource availability and labels (Step 3), then scores them by preferences (Step 4), finally selecting the highest scored node (Step 5).

What changes the Pod state from Pending to Running?

After binding the Pod to a node (Step 6), the node starts the Pod containers, changing the state to Running (Step 7).

Visual Quiz - 3 Questions

Look at the execution_table, at which step does the Pod get assigned to a node?

A Step 6

B Step 5

C Step 3

D Step 7

💡 Hint

Check the 'Bind Pod to node' action in Step 6 where Pod gets assigned to the node.

According to variable_tracker, what is the Pod state after Step 5?

A Running

B Pending

C Scheduled

D Unknown

💡 Hint

Look at the 'Pod State' row under 'After Step 5' column.

If no nodes have enough resources, what happens in the scheduling process?

A Pod immediately runs on any node

B Scheduler skips filtering and binds Pod anyway

C Pod stays Pending because no nodes pass filtering

D Pod is deleted automatically

💡 Hint

Refer to Step 3 in execution_table where nodes are filtered by resources.

Concept Snapshot

Pod scheduling controls where Pods run in a cluster.
Scheduler watches unscheduled Pods.
Filters nodes by resources and labels.
Scores nodes by preferences.
Binds Pod to best node.
Pod runs on assigned node.

Full Transcript

When you create a Pod in Kubernetes, it does not run immediately. Instead, it enters a Pending state waiting for the scheduler. The scheduler watches for new Pods that need placement. It checks all nodes in the cluster, filtering out those that lack enough resources or do not match required labels. Then it scores the remaining nodes based on preferences like resource availability or affinity rules. The scheduler picks the highest scored node and binds the Pod to it. Once bound, the node starts the Pod's containers, changing its state to Running. This process ensures Pods run on nodes that can support them, balancing load and respecting constraints.

Practice

1. What is the main role of scheduling in Kubernetes Pod placement?

easy

A. To update the container images inside Pods

B. To create new Pods automatically

C. To decide which node a Pod should run on

D. To delete unused Pods from the cluster

Solution

1. Step 1: Understand scheduling purpose

   Scheduling in Kubernetes is responsible for choosing the best node for a Pod to run on.

2. Step 2: Differentiate scheduling from other tasks

   Creating, deleting, or updating Pods is handled by other components, not the scheduler.

3. Final Answer:

   To decide which node a Pod should run on -> Option C

4. Quick Check:

   Scheduling = Pod node selection [OK]

Hint: Scheduling picks the node for Pods to run on [OK]

Common Mistakes:

• Confusing scheduling with Pod creation
• Thinking scheduler updates container images
• Assuming scheduler deletes Pods

2. Which of the following is a valid Kubernetes scheduler configuration to restrict Pods to nodes with label zone=us-east?

easy

A. nodeAffinity:
key: zone
operator: NotIn
values: [us-east]

B. nodeSelector:
region: us-east

C. nodeAffinity:
key: zone
operator: Exists

D. nodeSelector:
zone: us-east

Solution

1. Step 1: Identify correct nodeSelector syntax

   nodeSelector uses key-value pairs to select nodes; here, zone: us-east is correct.

2. Step 2: Check other options for correctness

   nodeSelector: region: us-east uses wrong key region. nodeAffinity: key: zone operator: NotIn values: [us-east] excludes us-east nodes. nodeAffinity: key: zone operator: Exists only checks if zone exists, not restricting to us-east.

3. Final Answer:

   nodeSelector: zone: us-east -> Option D

4. Quick Check:

   nodeSelector key=value matches node label [OK]

Hint: nodeSelector uses exact key-value pairs for node labels [OK]

Common Mistakes:

• Using wrong label keys in nodeSelector
• Confusing nodeAffinity operators
• Using NotIn instead of In for selection

3. Given this Pod spec snippet, what will happen if no nodes have label disk=ssd?

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disk
            operator: In
            values:
            - ssd

medium

A. Pod will be scheduled on any node ignoring the label

B. Pod will remain Pending until a node with disk=ssd is available

C. Pod will be scheduled on nodes without the label but with enough resources

D. Pod will be deleted automatically by the scheduler

Solution

1. Step 1: Understand requiredDuringScheduling nodeAffinity

   This rule means the Pod must be scheduled only on nodes matching the label disk=ssd.

2. Step 2: Check behavior if no matching nodes exist

   If no nodes have disk=ssd, the Pod cannot be scheduled and stays in Pending state.

3. Final Answer:

   Pod will remain Pending until a node with disk=ssd is available -> Option B

4. Quick Check:

   Required nodeAffinity = Pod waits for matching node [OK]

Hint: Required nodeAffinity blocks scheduling if no matching node [OK]

Common Mistakes:

• Thinking Pod schedules ignoring required nodeAffinity
• Assuming Pod gets deleted if unschedulable
• Confusing required and preferred nodeAffinity

4. You wrote this nodeAffinity in your Pod spec but the Pod is stuck in Pending state:

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchExpressions:
      - key: gpu
        operator: Exists
      - key: memory
        operator: In
        values:
        - high

What is the likely problem?

medium

A. No nodes have both labels gpu and memory=high

B. The syntax of nodeAffinity is invalid

C. The scheduler ignores nodeAffinity rules

D. Pod spec is missing container image

Solution

1. Step 1: Analyze nodeAffinity conditions

   Pod requires nodes with label gpu (any value) and memory=high.

2. Step 2: Check why Pod is Pending

   If no node has both labels, Pod cannot be scheduled and stays Pending.

3. Final Answer:

   No nodes have both labels gpu and memory=high -> Option A

4. Quick Check:

   Missing matching nodes = Pod Pending [OK]

Hint: Pod Pending often means no nodes match all affinity labels [OK]

Common Mistakes:

• Assuming syntax error without checking labels
• Thinking scheduler ignores affinity rules
• Blaming unrelated Pod spec parts

5. You want to ensure Pods with label app=frontend only run on nodes with label env=production, but allow Pods with app=backend to run anywhere. Which scheduling configuration achieves this?

hard

A. Add a nodeAffinity with requiredDuringScheduling for env=production only in frontend Pods

B. Use a nodeSelector with env=production in all Pods

C. Use a taint on production nodes and tolerate it in backend Pods

D. Add a preferredDuringScheduling nodeAffinity for env=production in backend Pods

Solution

1. Step 1: Understand requirement for frontend Pods

   Frontend Pods must run only on nodes labeled env=production. Backend Pods have no restriction.

2. Step 2: Choose correct scheduling control

   Adding requiredDuringScheduling nodeAffinity to frontend Pods enforces this. Backend Pods without affinity run anywhere.

3. Final Answer:

   Add a nodeAffinity with requiredDuringScheduling for env=production only in frontend Pods -> Option A

4. Quick Check:

   Required nodeAffinity limits frontend Pods; backend unrestricted [OK]

Hint: Use required nodeAffinity only on Pods needing strict placement [OK]

Common Mistakes:

• Applying nodeSelector to all Pods causing backend restriction
• Using preferred affinity which is not strict
• Misusing taints and tolerations for this case