Paste your manifests and see what they actually reserve: total CPU and memory across every replica, the QoS class per workload, how many nodes it needs, and the gap between what is reserved and what those pods are allowed to burst to.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Add it up. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
A container that can grow until the node evicts something, including itself
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3
template:
spec:
containers:
- name: app
resources:
requests:
cpu: 100m
memory: 128MiWhat the scheduler must find, which is requests times replicas
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 10
template:
spec:
containers:
- name: app
resources:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 500m
memory: 1GiThese are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Memory is incompressible. Without a limit a container grows until the kernel OOM kills something on the node, not necessarily itself.
Instead:Always set a memory limit. Equal to the request gives Guaranteed.
The request is the guarantee; the limit is a throttle that applies even when the node is idle.
Instead:Set requests carefully and be cautious with CPU limits.
The scheduler must find requests times replicas, and a request that fits once may not fit ten times.
Instead:Size against the total and the largest node.
The arithmetic is simple. Knowing which number the cluster is sized by is the part that saves money.
A cluster is sized by the sum of requests, not by usage. Every replica of every container reserves its request whether it uses it or not, so a workload asking for 2 CPU and using 0.2 is being paid for ten times over. This adds it all up and draws the reserved capacity to scale against what those pods may burst to.
They run to completion before the app starts, so a pod reserves the larger of the init and the running requirement rather than the sum. Tools that add them together overstate what a cluster needs, sometimes considerably when a migration container asks for far more than the app.
Guaranteed, Burstable or BestEffort, using Kubernetes' own rules: Guaranteed needs request to equal limit for both CPU and memory on every container. This is what decides which pods get killed first when a node runs out of memory, and BestEffort pods go first.
A limit far above the request means the container is throttled the moment it uses what it was told it could. Throttling is applied per 100ms period, so a burst that needs 50ms of full CPU is stretched across several periods and appears as latency nothing in the dashboards explains.
Two numbers per resource per container, and almost every Kubernetes cost and reliability problem traces back to how they were chosen. They do different jobs and confusing them is expensive in both directions.
The scheduler subtracts every pod's request from a node's allocatable capacity and will not place a pod that does not fit. That reservation is held whether the container uses it or not, which means requests decide how many nodes you run, and therefore what you pay. Nothing else in Kubernetes affects the bill as directly.
node: 4 CPU allocatable
pod A requests 1 CPU, uses 0.1 -> 1 CPU reserved
pod B requests 1 CPU, uses 0.1 -> 1 CPU reserved
pod C requests 1 CPU, uses 0.1 -> 1 CPU reserved
pod D requests 1 CPU, uses 0.1 -> 1 CPU reserved
node is full. actual usage: 0.4 CPU out of 4.CPU is compressible, so exceeding a CPU limit throttles the container: it keeps running, more slowly. Memory is not compressible, so exceeding a memory limit kills it: the container is OOMKilled and restarted, mid-request. That asymmetry is why a memory limit should almost always equal the memory request, and why a CPU limit is a more debatable choice.
Kubernetes classifies every pod from its requests and limits, and uses that class when a node runs out of memory. Guaranteed pods are evicted last, BestEffort first. This is not configurable directly: you get the class your numbers imply, which is why a pod you consider critical can be first in the queue simply because nobody set its requests.
Guaranteed every container sets both, and request == limit
Burstable something is set, but not matching
BestEffort nothing set at all
evicted first: BestEffort, then Burstable over its request,
then GuaranteedA limit of 500m does not mean half a core averaged over a second. The kernel gives the container 50ms of CPU in every 100ms period, and when that is spent the container waits, even if the node is idle. A request handler needing 80ms of solid CPU therefore takes at least 150ms of wall clock. This is why a service can show p99 latency far above its median while every CPU graph looks calm.
Init containers run one at a time and finish before the app containers start. A pod's effective request is therefore the larger of the biggest init container and the sum of the running containers, not the total of both. A migration init container asking for 2 CPU sets the floor for scheduling that pod, but does not permanently reserve 2 CPU on top of the app.