Requests and limits do different jobs
Requests are the reservation the scheduler uses to place a pod on a node, while limits are the ceiling the container cannot cross while running. How you fill them decides whether the pod is Guaranteed, Burstable or BestEffort, and the tool shows the class with the reason behind it. Setting only limits fills the requests with the same values.
What happens above the ceiling also differs per resource. CPU above its limit is throttled, so the container slows but survives, while memory above its limit ends the container with an OOMKill. Whether the replicas fit is calculated from the sum of requests against allocatable capacity, not from limits, following the Kubernetes documentation checked in October 2026.
No recommended numbers are offered, because the right values depend on the workload and traffic and no authority publishes them. Measure real usage with monitoring and type that in. LimitRange, vertical autoscaling, taints and affinity, and the share daemonsets take are not modelled.
Frequently Asked Questions
Set both CPU and memory limits and leave requests blank, and the requests are filled with the same values, which makes the pod Guaranteed. Setting only one of them leaves it Burstable.
CPU is time-shared, so going over the ceiling only throttles the container. Memory already handed out cannot be taken back, so crossing the memory limit ends the container with an OOMKill.
The scheduler ignores limits and only checks that the sum of requests stays within allocatable capacity. That is why limits can add up past the node and the pods still schedule, right up until they all run at their ceiling.