Full lesson
Explore the full explanation, examples, and visuals at your own pace.
Requests guide placement. Limits constrain runtime use.
A Pod's requests guide scheduling; its limits constrain runtime use. One Pod reveals CPU and memory outcomes.
One container in Pod web
Pod web has one container, and these resource settings apply to that container. It requests 250 millicores of CPU and 128 mebibytes of memory, with limits of 500 millicores and 256 mebibytes. Requests guide placement; limits constrain resource use at runtime.
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
containers:
- name: web
image: nginx:stable
resources:
requests:
cpu: 250m
memory: 128Mi
limits:
cpu: 500m
memory: 256MiThe requests must fit
The Scheduler checks whether a Node has enough available allocatable capacity for web’s requests: 250 millicores of CPU and 128 mebibytes of memory. Because those requests fit on the assumed Node, it can place the Pod there. Its higher limits don’t determine this scheduling decision.
CPU demand above 500m is throttled
Requests guide scheduling; limits constrain runtime use. Web's 700m CPU demand exceeds its 500m limit, so Kubernetes throttles CPU rather than terminating the container. It can stay running, but it won't get the extra CPU time it demands.
Memory beyond 256Mi can kill the container
web's 128Mi request doesn't cap its memory; it can grow to 300Mi. But that crosses the 256Mi limit. Unlike CPU, which is throttled above its limit, memory overage can lead the kernel to OOM-kill the container.
The web container uses more memory than requested but stays below its memory limit. What follows from these settings alone?
Let's think this through. The web container uses more memory than requested but stays below its memory limit. What follows from these settings alone? A: It is immediately killed. B: It may keep running. C: Its memory is throttled to the request. Choose an answer, or just think it through. I'll explain in a moment.
- It is immediately killed
- It may keep running
- Its memory is throttled to the request
The web container uses more memory than requested but stays below its memory limit. What follows from these settings alone?
The answer is B: It may keep running. A memory request helps the scheduler place the Pod; it is not a runtime cap. The container can use more than requested while staying below its limit, though node memory pressure can still affect it.
- It is immediately killed
- It may keep running
- Its memory is throttled to the request
Termination is not the end of the Pod
When memory use crosses web’s 256Mi limit, Kubernetes can terminate the container; its status may show OOMKilled. The Pod itself can remain, and under a Deployment the restart policy normally starts the container again. If this repeats, investigate its memory demand and configuration.
What to check in practice
When web is Pending, compare its requests with the node’s available allocatable resources; raising limits won’t make that request fit. For slow CPU work, look for throttling. After restarts, check whether the reason is OOMKilled.
- Pending Pod: do requests fit?
- Slow CPU work: check throttling.
- Restarts: check for OOMKilled.
Requests book capacity; limits police usage at runtime.
Requests book capacity; limits police usage at runtime. CPU is throttled; memory can trigger OOM termination.