Node selectors for simple scheduling in Kubernetes - Commands & Configuration

Introduction

Sometimes you want your app to run only on certain computers in your cluster. Node selectors help you pick those computers by matching labels you set on them.

When you want a pod to run only on nodes with special hardware like GPUs.

When you want to keep certain apps on nodes in a specific data center or zone.

When you want to separate workloads by node type, like fast SSD nodes versus regular nodes.

When you want to avoid running some pods on nodes reserved for system tasks.

When you want to test an app on a specific node before wider rollout.

Config File - pod.yaml

pod.yaml

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

This file creates a pod named example-pod running an nginx container.

The nodeSelector section tells Kubernetes to schedule this pod only on nodes labeled with disktype=ssd.

Commands

This command adds the label disktype=ssd to the node named node1. This label is used by the pod's node selector to find a matching node.

Terminal

kubectl label nodes node1 disktype=ssd

Expected Output

node/node1 labeled

This command creates the pod defined in pod.yaml. Kubernetes will try to schedule it on a node with the label disktype=ssd.

Terminal

kubectl apply -f pod.yaml

Expected Output

pod/example-pod created

This command shows the pods with extra details including the node they are running on. You can verify the pod is on the correct node.

Terminal

kubectl get pods -o wide

Expected Output

NAME          READY   STATUS    RESTARTS   AGE   IP           NODE    NOMINATED NODE   READINESS GATES

example-pod   1/1     Running   0          10s   10.244.1.5   node1   <none>           <none>

→

-o wide - Shows detailed information including the node name

This command shows detailed information about the pod, including the node selector and the node where it is scheduled.

Terminal

kubectl describe pod example-pod

Expected Output

Name:         example-pod

Namespace:    default

Node:         node1/192.168.1.10

Start Time:   Thu, 01 Jan 2024 12:00:00 +0000

Labels:       <none>

Annotations:  <none>

Status:       Running

IP:           10.244.1.5

Containers:

  example-container:

    Image:        nginx

    State:        Running

    Ready:        True

    Restart Count: 0

Conditions:

  Type           Status

  Initialized    True 

  Ready          True 

  ContainersReady True 

  PodScheduled   True 

Node-Selectors:  disktype=ssd

Key Concept

If you remember nothing else from this pattern, remember: node selectors let you tell Kubernetes to run pods only on nodes with matching labels.

Common Mistakes

Not labeling any node with the key-value used in nodeSelector.

Kubernetes cannot find a matching node, so the pod stays pending and never runs.

Always label at least one node with the exact key and value used in the pod's nodeSelector before creating the pod.

Using a different label key or value in the pod than what is on the node.

The pod will not match any node and remain unscheduled.

Double-check that the label key and value in the pod's nodeSelector exactly match the node's label.

Forgetting to apply the pod manifest after labeling nodes.

The pod won't be created or scheduled, so no workload runs.

Run 'kubectl apply -f pod.yaml' after labeling nodes to create and schedule the pod.

Summary

Label nodes with key-value pairs to identify their characteristics.

Use nodeSelector in pod specs to require pods run only on nodes with matching labels.

Apply the pod manifest and verify the pod runs on the correct node using kubectl commands.

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