Node selectors for simple scheduling in Kubernetes - Step-by-Step Execution

Process Flow - Node selectors for simple scheduling

Pod Spec Created

↓

Add nodeSelector Field

↓

Pod Submitted to API Server

↓

Scheduler Checks Nodes

↓

Match Node Labels with nodeSelector?

No→Wait or Fail

Yes↓

Pod Assigned to Matching Node

↓

Pod Runs on Selected Node

The pod spec includes a nodeSelector field. The scheduler matches this with node labels to assign the pod to a suitable node.

Execution Sample

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  nodeSelector:
    disktype: ssd
  containers:
  - name: app
    image: nginx

This pod requests scheduling only on nodes labeled with disktype=ssd.

Process Table

Step	Action	Scheduler Check	Result	Pod State
1	Pod spec created with nodeSelector disktype=ssd	N/A	Pod ready for scheduling	Pending
2	Pod submitted to API server	N/A	Pod accepted	Pending
3	Scheduler scans nodes	Check node labels	Found nodes with disktype=ssd	Pending
4	Scheduler matches nodeSelector with node labels	Match disktype=ssd?	Match found on node-1	Pending
5	Scheduler assigns pod to node-1	Assignment done	Pod bound to node-1	Running
6	Pod starts running on node-1	N/A	Pod running	Running

💡 Pod assigned to node with matching label disktype=ssd and starts running.

Status Tracker

Variable	Start	After Step 3	After Step 5	Final
Pod State	Not created	Pending	Running	Running
Node Selected	None	None	node-1	node-1

Key Moments - 3 Insights

Why does the pod stay in Pending state before scheduling?

The pod is Pending because the scheduler has not yet assigned it to a node. See execution_table step 2 and 3 where the pod is accepted but not assigned.

What happens if no node matches the nodeSelector labels?

The pod remains Pending and will not be scheduled until a matching node appears. This is shown by the scheduler check in step 4 where no match would cause waiting.

Can the pod run on a node without the matching label?

No, the scheduler enforces nodeSelector strictly. The pod only runs on nodes matching the labels, as shown in step 5 and 6.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the scheduler assign the pod to a node?

A Step 4

B Step 3

C Step 5

D Step 6

💡 Hint

Check the 'Result' column for the assignment action in the execution_table.

According to the variable tracker, what is the pod state after step 3?

A Pending

B Running

C Succeeded

D Failed

💡 Hint

Look at the 'Pod State' row and the 'After Step 3' column in variable_tracker.

If the nodeSelector label was changed to disktype=hdd, what would happen in the execution table?

A Scheduler finds matching nodes and assigns pod immediately

B Pod remains Pending if no node has disktype=hdd label

C Pod runs on any node regardless of label

D Pod is deleted automatically

💡 Hint

Refer to key_moments about what happens if no node matches the nodeSelector.

Concept Snapshot

Node selectors let you tell Kubernetes to run pods only on nodes with specific labels.
Add a nodeSelector field in pod spec with key-value pairs.
Scheduler matches these labels to node labels.
Pod stays Pending if no matching node is found.
Simple way to control pod placement without complex rules.

Full Transcript

Node selectors are a simple way to schedule pods on specific nodes in Kubernetes. You add a nodeSelector field to the pod specification with key-value pairs that must match node labels. When the pod is submitted, the scheduler looks for nodes with matching labels. If it finds one, it assigns the pod to that node and the pod starts running. If no matching node exists, the pod stays in Pending state until a suitable node appears. This method helps control where pods run using simple label matching.

Practice

1. What is the main purpose of using nodeSelector in a Kubernetes Pod specification?

easy

A. To limit the number of pods running in the cluster

B. To schedule pods only on nodes with specific labels

C. To automatically update pods when nodes change

D. To create a backup of pod data on nodes

Solution

1. Step 1: Understand nodeSelector role

   The nodeSelector field in a Pod spec is used to specify labels that a node must have for the pod to be scheduled there.

2. Step 2: Compare options with nodeSelector purpose

   Only To schedule pods only on nodes with specific labels correctly describes this scheduling control. Other options describe unrelated features.

3. Final Answer:

   To schedule pods only on nodes with specific labels -> Option B

4. Quick Check:

   nodeSelector = schedule pods on labeled nodes [OK]

Hint: nodeSelector matches pod to node labels for placement [OK]

Common Mistakes:

• Thinking nodeSelector limits pod count
• Confusing nodeSelector with pod updates
• Assuming nodeSelector backs up pod data

2. Which of the following is the correct syntax to specify a nodeSelector in a Pod YAML manifest?

easy

A. nodeSelector: disktype=ssd

B. nodeSelector:
- disktype: ssd

C. nodeSelector:
disktype: ssd

D. nodeSelector: [disktype=ssd]

Solution

1. Step 1: Recall nodeSelector YAML format

   nodeSelector is a map of key-value pairs under the nodeSelector field, indented properly.

2. Step 2: Check each option's syntax

   nodeSelector: disktype: ssd uses correct YAML mapping with key and value properly indented. Options B, C, and D use invalid YAML or wrong formats.

3. Final Answer:

   nodeSelector: disktype: ssd -> Option C

4. Quick Check:

   nodeSelector uses key: value map in YAML [OK]

Hint: Use key: value under nodeSelector with proper indentation [OK]

Common Mistakes:

• Using list syntax instead of map
• Writing nodeSelector as a string
• Incorrect indentation causing YAML errors

3. Given the following node labels:

node1: disktype=ssd
node2: disktype=hdd

And this Pod spec snippet:

spec:
  nodeSelector:
    disktype: ssd

On which node will the Pod be scheduled?

medium

A. node1

B. node2

C. Either node1 or node2

D. No node, pod will remain pending

Solution

1. Step 1: Match pod nodeSelector with node labels

   The pod requires a node with label disktype=ssd. node1 has this label, node2 does not.

2. Step 2: Determine pod scheduling

   Since only node1 matches the label, the pod will be scheduled on node1.

3. Final Answer:

   node1 -> Option A

4. Quick Check:

   Pod nodeSelector matches node1 label [OK]

Hint: Pod schedules only on nodes matching all nodeSelector labels [OK]

Common Mistakes:

• Assuming pod can schedule on any node
• Ignoring label key-value exact match
• Thinking pod schedules on multiple nodes simultaneously

4. You wrote this Pod spec:

spec:
  nodeSelector:
    disk-type: ssd

But your nodes have label disktype=ssd (no dash). What will happen when you try to schedule the Pod?

medium

A. Pod will remain pending, no matching nodes found

B. Pod will schedule on nodes with label disktype=ssd

C. Pod will schedule on nodes with label disk-type=ssd

D. Pod will schedule on any available node

Solution

1. Step 1: Compare nodeSelector key with node labels

   The pod requests nodes with label disk-type=ssd, but nodes have disktype=ssd. The keys differ by a dash.

2. Step 2: Understand label matching behavior

   Labels must match exactly. Since no node has disk-type=ssd, pod cannot be scheduled.

3. Final Answer:

   Pod will remain pending, no matching nodes found -> Option A

4. Quick Check:

   Label keys must match exactly for nodeSelector [OK]

Hint: Label keys must match exactly, including dashes [OK]

Common Mistakes:

• Assuming partial key match works
• Thinking pod schedules on any node if no match
• Confusing label key spelling

5. You want to ensure a Pod runs only on nodes labeled region=us-west and disktype=ssd. Which is the correct nodeSelector configuration?

hard

A. nodeSelector:
region: us-west, disktype: ssd

B. nodeSelector:
region=us-west
disktype=ssd

C. nodeSelector:
- region=us-west
- disktype=ssd

D. nodeSelector:
region: us-west
disktype: ssd

Solution

1. Step 1: Understand nodeSelector format for multiple labels

   nodeSelector is a map of key-value pairs, each on its own line with proper indentation.

2. Step 2: Evaluate each option's syntax

   nodeSelector: region: us-west disktype: ssd correctly lists two key-value pairs. nodeSelector: region: us-west, disktype: ssd uses invalid comma syntax. nodeSelector: - region=us-west - disktype=ssd uses list syntax which is invalid. nodeSelector: region=us-west disktype=ssd uses equals signs incorrectly.

3. Final Answer:

   nodeSelector: region: us-west disktype: ssd -> Option D

4. Quick Check:

   Multiple labels in nodeSelector use separate key: value lines [OK]

Hint: List each label as key: value pair under nodeSelector [OK]

Common Mistakes:

• Using commas to separate labels
• Using list syntax instead of map
• Using equals signs instead of colon in YAML