The mechanism
The scheduler evaluates candidate nodes against requirements and preferences. Resource requests, node selectors, affinity, taints and topology rules can all affect placement. A Pod can remain Pending even when the cluster appears mostly idle if no eligible node satisfies its combined constraints.
Hard requirements filter candidates; soft preferences rank otherwise eligible choices. A toleration permits consideration of a tainted node but does not force placement there. A node label identifies a property only as reliably as the process that assigns and protects it.
For ParcelOps, availability may require replicas across failure domains. That goal competes with limited capacity and storage topology. Write down which constraints are essential and which are preferences before responding to scheduling failures.
Worked example
This offline scheduling worksheet shows why total free capacity can mislead. Numbers are illustrative. No node labels or taints are changed in the lab.
Pod needs: 200m CPU, 256Mi memory, zone=east
Node A: east, 100m request capacity remaining -> insufficient CPU
Node B: west, 2000m remaining -> wrong required zone
Node C: east, 1000m remaining, untolerated taint -> excluded
Result: no eligible node despite aggregate spare capacityPractice: predict, inspect, explain
Offline exercise. Change only one requirement or node condition at a time and predict the candidate set. Explain the risk of removing the zone requirement if a persistent volume is tied to that zone. Then replace a hard preference with a soft one and describe the availability trade-off.
Expected observation: a scheduling decision is the intersection of constraints, not a cluster-wide free-memory total. A useful incident note identifies the exact failed requirement and why changing it is acceptable. Avoid changing policy merely to make Pending disappear.
Troubleshooting and trade-offs
If events show insufficient resources, review requests and eligible nodes. If affinity excludes every node, compare labels with the intended topology. If a toleration is missing, determine whether the taint intentionally protects a special workload pool. Do not add universal tolerations or bind directly to nodes as a default workaround.
Interview practice
Does a toleration guarantee placement?
No. It allows a Pod to tolerate a taint, but other constraints still apply and the scheduler still chooses among eligible nodes.
Why distinguish hard and soft rules?
Hard rules can make placement impossible; soft rules express preferences that can yield when necessary. The choice affects both availability and intent.
Completion check
Explain an unschedulable Pod using a candidate-node table and one justified corrective option.
Sources and version notes
Baseline checked 6 October 2026: the official release page lists Kubernetes 1.37.1. Verify your cluster and distribution prerequisites. All manifests are offline teaching examples; no cluster mutations or cloud resources are executed by this handbook.
- Official documentation: Assign pod node
- Official documentation: Manage resources containers
- Official documentation: Persistent volumes
Make the understanding yours.
Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.
Self-assessed reading progress. This does not certify that a lab ran or a system is secure.