Resource requests and feasibility

A request represents the resource quantity used by the scheduling or admission policy. A limit governs a runtime constraint under the platform’s enforcement mechanism. Measured usage records what the workload consumed over a particular observation interval. They can differ substantially. An idle process can retain its resource request, and a workload may consume more CPU than its request when permitted capacity is available. Do not infer that unused requested capacity has automatically become schedulable capacity under the same policy.

In Kubernetes, CPU and memory requests inform scheduling, while limits have resource-specific runtime behavior. CPU enforcement can throttle execution; memory pressure or limit enforcement can lead to termination rather than slowing memory use smoothly. Device resources can follow additional allocation and sharing contracts. Avoid transferring a CPU-sharing intuition to GPU memory without checking the actual implementation. The declared values should reflect supported workload behavior and operational policy, not simply the smallest numbers that make one test placement succeed.

Use allocatable capacity after system reservations rather than the machine’s advertised total. Include relevant overhead and account for the workload’s execution shape, such as simultaneously running containers or worker replicas. Then check hard constraints: device type, node labels, storage availability, topology, and required affinity. Summing free GPUs across the cluster does not place a task requiring several compatible devices on one host. A quota admission decision may also be separate from the final pod-to-node scheduling decision.

Declared accounting can fit while actual execution still performs poorly. Requests do not model every shared bottleneck, such as network fabric contention, memory bandwidth, or accelerator interconnect. Collect per-stage metrics and peak usage, including model loading and checkpoint bursts. Adjust declarations through a controlled process that watches failures and latency. Blindly shrinking requests because average usage is low can create overcommitment that appears efficient until synchronized bursts arrive. Record the safety margin and the evidence behind it.

Normalize each dimension by its own capacity when comparing shapes, but retain the original units for decisions and debugging. A normalized vector can show that memory is tight while CPU has room. It cannot reveal whether the requested accelerator model exists or whether a storage volume is attachable. Report concrete infeasibility reasons rather than a generic pending status: insufficient requested memory, incompatible device type, and unsatisfied topology imply different remedies. A larger cluster may not fix a constraint that every new node also violates.

Use the vector lab for a two-resource normalized example. Reset, set angle to 45 degrees and magnitude to 1, predict both components, then Step. Treat unit capacity in each positive axis as a separate resource budget. For a fresh comparison, Reset and explicitly set angle to 45 degrees and magnitude to 2, predict whether either component exceeds one, then Step. The instrument draws one vector and projections only; it has no nodes, live allocations, limits, or scheduling decisions.