LEARN. PRACTICE. GROW.Concept and mechanism
The scheduler uses resource requests and constraints to choose an eligible node. A chart showing low CPU utilization does not establish sufficient capacity for additional committed requests. Requests and limits answer different questions: placement and resource sharing on one side, consumption ceilings on the other. On Linux, a CPU limit can cause throttling while memory exhaustion can terminate a process. Use explicit units: 500m CPU means 0.5 CPU; 512Mi is a memory quantity. This lesson’s examples use per-container requests without a Pod-level budget, init containers, or additional overhead so the arithmetic can be checked.
Guided application
In a fictional exercise, a node has 1800m available for new requests and each Pod requests 450m. Four fit by the CPU criterion if memory and other conditions also permit. Five exceed that budget even during low utilization. When PodScheduled is false, read scheduler events before lowering requests. A NoSchedule taint requires a matching toleration; that toleration removes one constraint but neither guarantees placement nor exclusively selects the node. Labels, affinity, storage, and capacity remain relevant. If an application was scheduled but is waiting for its image, adding capacity may not fix the problem. Pending covers different situations; distinguish overall phase, conditions, and each container’s state.
1800m / 450m = four Pods by CPU alone; this is not a global placement guarantee.
Common pitfalls
Low utilization as uncommitted requests; toleration as reservation; Pending as a single cause.
Related topics: Workloads and desired state · Traffic and probes · Configuration and data
Decide using requests, capacity, and events describing the actual constraint.
Reference: Requests limits and scheduling · Kubernetes v1.37 concepts; current official documentation consulted 2026-09-30; cluster versions and plugin capabilities must be confirmed