Why scheduling controls Pod placement in Kubernetes - Why It Works

Introduction

When you run applications in Kubernetes, you want them to run on the best possible machines. Scheduling decides which machine (node) will run your app (pod) based on rules and available resources. This helps your app run smoothly and efficiently.

When you want to make sure your app runs on a node with enough CPU and memory.

When you want to keep certain apps away from each other to avoid conflicts.

When you want to run apps only on specific nodes with special hardware like GPUs.

When you want to spread your app copies across different nodes for safety.

When you want to control where your app runs to save costs or improve speed.

Commands

This command shows all pods with details including which node each pod is running on. It helps you see pod placement decided by the scheduler.

Terminal

kubectl get pods -o wide

Expected Output

NAME           READY   STATUS    RESTARTS   AGE   IP           NODE           NOMINATED NODE   READINESS GATES

my-app-pod-1   1/1     Running   0          5m    10.244.1.5   worker-node-1  <none>           <none>

→

-o wide - Shows extra details including node name where pod is placed

This command shows detailed information about the pod including events and scheduling decisions. It helps understand why the pod was placed on a specific node.

Terminal

kubectl describe pod my-app-pod-1

Expected Output

Name:         my-app-pod-1

Namespace:    default

Node:         worker-node-1/192.168.1.10

Start Time:   Thu, 01 Jun 2024 10:00:00 +0000

Labels:       app=my-app

Status:       Running

Events:

  Type    Reason     Age   From               Message

  ----    ------     ----  ----               -------

  Normal  Scheduled  5m    default-scheduler  Successfully assigned default/my-app-pod-1 to worker-node-1

This command lists all nodes in the cluster with their status and resources. It helps you see where pods can be scheduled.

Terminal

kubectl get nodes

Expected Output

NAME           STATUS   ROLES    AGE   VERSION

worker-node-1  Ready    <none>   10d   v1.27.3

worker-node-2  Ready    <none>   10d   v1.27.3

Key Concept

If you remember nothing else from this pattern, remember: Kubernetes scheduler decides the best node for your pod based on resource needs and rules to keep your app running well.

Common Mistakes

Ignoring pod resource requests and limits in pod specs

Without resource requests, scheduler cannot place pods properly, leading to overloaded nodes or pod failures.

Always specify resource requests and limits in pod definitions to guide the scheduler.

Trying to manually assign pods to nodes without using proper node selectors or affinity

Pods may not schedule or may move unexpectedly if manual placement is not done with Kubernetes scheduling features.

Use nodeSelector, node affinity, or taints and tolerations to control pod placement properly.

Summary

The Kubernetes scheduler decides which node will run each pod based on resource needs and rules.

You can check pod placement with 'kubectl get pods -o wide' and 'kubectl describe pod'.

Proper resource requests and node selection rules help the scheduler place pods efficiently.

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