LEARN. PRACTICE. GROW.Concept and mechanism
The scheduler must find a node satisfying Pod requests and other constraints. Low instantaneous usage does not remove capacity already reserved by requests. A node with four allocatable CPUs and one CPU requested by other Pods has 3000m remaining; two new 1500m Pods fit by CPU if nothing else prevents placement. Memory headroom fragmented across nodes also cannot be added to place one Pod. After startup, requests and limits continue to serve different purposes. OOMKilled calls for investigation of memory usage, limits, and application profile instead of increasing CPU or removing reservations without evidence.
Guided application
Choose the controller from the work lifecycle. A DaemonSet represents an agent on eligible nodes with suitable selection and tolerations. A Job represents finite work, but the application must still tolerate repetition. In a financial batch, one completion does not guarantee a single external posting: use a stable key and a mechanism recognizing confirmed effects. Before any change, confirm cluster, identity, namespace, and object. In a capacity rehearsal, retain scheduling events, requests, limits, and functional results. The technical manager’s decision should consider the batch deadline, added cost, and impact on online services sharing the cluster.
Two nodes with 1024Mi headroom each cannot place a 1536Mi Pod. Enough headroom is needed on one compatible node.
Common pitfalls
Observed usage treated as reservation; adding node memory; limits confused with requests; one completion treated as exactly one effect; assumed context.
Related topics: Services, DNS, and network policies · Persistent data and proportionate access
Placement unit, lifecycle, and effect semantics guide design.
Reference: Resource management · KCNA current four-domain curriculum; edition date unconfirmed