A container may need extra CPU for a short burst, but it should not be able to consume resources without a bound. In Kubernetes, a resource limit sets the maximum CPU or memory a running container may use. Set it alongside a resource request: the request determines where the Pod can be scheduled, while the limit constrains usage after it starts. The scheduler considers requests, not limits, when placing Pods. section 5.1.1
Listing 5.2 Chapter05/5.1.1_PodResources/deploy_requests_limits.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: timeserver
spec:
replicas: 3
selector:
matchLabels:
pod: timeserver-pod
template:
metadata:
labels:
pod: timeserver-pod
spec:
containers:
- name: timeserver-container
image: docker.io/wdenniss/timeserver:3
resources:
requests:
cpu: 200m
memory: 250Mi
limits: #1
cpu: 300m #1
memory: 400Mi #1
#1 The resource limits of this container. The container can use up to 30% of a CPU core and 400 MiB memory.
The Deployment sets a container request of 200m CPU and 250Mi memory, with higher limits of 300m CPU and 400Mi memory. That leaves room to burst above the requested amounts. section 5.1.1
The consequence of reaching a limit depends on the resource:
- Exceed the memory limit and the container is terminated and restarted. A limit too low for startup or normal operation can cause repeated out-of-memory failures. section 5.1.1 section 5.2.1
- Exceed the CPU limit and CPU usage is throttled rather than restarted. section 5.1.1
Limits also affect a Pod’s quality of service. When every container’s limits equal its requests, the Pod is in the guaranteed class: it has predictable allocated resources and is not evicted during resource contention. Higher limits than requests permit bursting when spare capacity exists, but performance can change if the Pod later runs on a busier node. A Pod with neither requests nor limits is best effort. section 5.1.2 section 5.1.3
Choose values by observing the workload, not by treating a high limit as reserved capacity. Start with a generous request and, while resource needs are uncertain, consider leaving limits unset. Check startup usage with `kubectl top pods`, then observe the Pod under realistic load and over time. Set the memory request high enough for sustained needs, with a buffer; a higher memory limit does not guarantee spare node capacity. Frequent evictions point to requests that may need increasing, while repeated out-of-memory restarts call for reviewing memory use and the limit. section 5.2 section 5.2.1 section 5.1.3
Trading CPU cost for burst capacity
For many low-traffic websites, a 50m CPU request and a 1000m limit can allow each container to burst toward a full core. This can fit more Pods on a node, but simultaneous bursts can degrade performance. Keep requests sufficient for a reasonable base load rather than depending on spare CPU. section 5.2.3
