KCNA — Scheduling Concepts
Scheduling Concepts
The kube-scheduler decides which node each pod should run on. Understanding scheduling concepts helps you know how Kubernetes places workloads efficiently.
How the Scheduler Works
The scheduler follows a two-step process:
Step 1: Filtering
Eliminate nodes that cannot run the pod:
| Filter Reason | Example |
|---|---|
| Insufficient resources | Node doesn’t have enough CPU or memory |
| Node not ready | Node is in NotReady state |
| Taints | Node is tainted and pod doesn’t have matching toleration |
| Node selector mismatch | Pod requires disk=ssd but node doesn’t have that label |
| Volume constraints | Required volume can’t be attached to this node |
Step 2: Scoring
Rank remaining nodes and pick the best:
| Score Factor | What It Considers |
|---|---|
| Resource balance | Prefers nodes with more available resources |
| Affinity | Prefers nodes that match pod affinity rules |
| Spreading | Prefers spreading pods across nodes for high availability |
All nodes → [Filter] → Eligible nodes → [Score] → Best node → Assign pod
Node Selectors
The simplest way to control pod placement — require a specific node label:
spec:
nodeSelector:
disk: ssd # Only schedule on nodes with label disk=ssd
| Aspect | Details |
|---|---|
| How it works | Pod only runs on nodes with matching labels |
| Flexibility | Simple key-value matching only |
| Use case | When you need pods on specific hardware (GPU, SSD, etc.) |
Node Affinity
A more powerful version of node selectors with flexible matching:
| Type | Behavior |
|---|---|
| requiredDuringSchedulingIgnoredDuringExecution | Hard requirement — pod won’t schedule if no matching node exists |
| preferredDuringSchedulingIgnoredDuringExecution | Soft preference — scheduler tries to match but falls back to other nodes |
Exam tip: “IgnoredDuringExecution” means if a node’s labels change after the pod is already running, the pod is NOT evicted.
Taints and Tolerations
Taints are applied to nodes to repel pods. Tolerations are applied to pods to allow them onto tainted nodes.
Node (tainted): "Don't put regular pods here"
Pod (toleration): "I'm OK with that taint — let me in"
Taint Effects
| Effect | Behavior |
|---|---|
| NoSchedule | New pods without the toleration won’t be scheduled on this node |
| PreferNoSchedule | Scheduler tries to avoid this node, but will use it if needed |
| NoExecute | Existing pods without the toleration are evicted; new pods aren’t scheduled |
Common Use Cases
| Scenario | Taint | Purpose |
|---|---|---|
| Control plane nodes | node-role.kubernetes.io/control-plane:NoSchedule |
Keep user workloads off master nodes |
| GPU nodes | gpu=true:NoSchedule |
Reserve for GPU workloads only |
| Maintenance | maintenance=true:NoExecute |
Drain node for maintenance |
Pod Affinity and Anti-Affinity
Control where pods run relative to other pods:
| Type | Purpose | Example |
|---|---|---|
| Pod Affinity | Schedule pods together | “Put my cache pods on the same node as my app pods” |
| Pod Anti-Affinity | Keep pods apart | “Don’t put two replicas of my app on the same node” |
Anti-affinity is important for high availability — if a node fails, you don’t want all replicas to be on that node.
Resource-Based Scheduling
The scheduler uses resource requests (not limits) to decide placement:
resources:
requests:
cpu: "500m" # Scheduler ensures the node has 500m CPU available
memory: "256Mi" # Scheduler ensures the node has 256Mi memory available
| Concept | Details |
|---|---|
| Requests | What the scheduler looks at — minimum guaranteed resources |
| Limits | NOT used for scheduling — only enforced at runtime |
| Overcommit | If no requests are set, pods can all land on one node and compete for resources |
Summary Table
| Concept | Controls | Applied To | Purpose |
|---|---|---|---|
| Node Selector | Node label matching | Pod | Simple — “run on this type of node” |
| Node Affinity | Node label matching (advanced) | Pod | Flexible — required or preferred |
| Taints | Repel pods | Node | “Keep pods away” |
| Tolerations | Tolerate taints | Pod | “I’m OK running on that tainted node” |
| Pod Affinity | Co-locate with other pods | Pod | “Run near these pods” |
| Pod Anti-Affinity | Separate from other pods | Pod | “Don’t run near these pods” |
| Resource Requests | Capacity-based placement | Pod | “Need at least this much CPU/memory” |
Key Takeaways for the Exam
- The scheduler uses filtering (eliminate) then scoring (rank) to select the best node
- Node selectors are simple label-based placement (“run on SSD nodes”)
- Node affinity is a more flexible version with required/preferred rules
- Taints repel pods from nodes; tolerations let pods override taints
- Three taint effects: NoSchedule, PreferNoSchedule, NoExecute
- Pod anti-affinity ensures replicas spread across nodes for high availability
- Scheduling uses resource requests, not limits
What’s Next?
Test your understanding of Kubernetes resources with practice questions.
