A Pod needs enough CPU and memory to run, but Kubernetes needs to know those needs before choosing a node. A resource request declares the amount expected for each container. The scheduler uses requests to match Pods with node capacity. For a production Deployment, specify them in the Pod template rather than leaving placement to spare capacity and risking resource starvation. section 5.0 section 5.1.1
Listing 5.1 Chapter05/5.1.1_PodResources/deploy_requests.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: #1
cpu: 200m #1
memory: 250Mi #1
#1 The resource requests of this container
The Deployment sets requests under its container’s `resources` field: `cpu: 200m` requests 20% of one CPU core, and `memory: 250Mi` requests 250 MiB. section 5.1.1
A request is not a ceiling. A container may use more when capacity is available; a resource limit sets how far it may go. This distinction lets a Pod handle a burst, but spare capacity can disappear when other Pods need it. If consistent resources matter more than bursting, set limits equal to requests. Pods with neither requests nor limits are best effort, the lowest quality-of-service class. section 5.1.1 section 5.1.2
Requests also matter when a node runs short of resources. Kubernetes considers Pods using more than their requests for eviction, accounting for priority and excess usage. A Deployment can reschedule an evicted Pod, but frequent evictions can reduce availability. Treat repeated `Evicted` statuses as a reason to revisit requests and cluster capacity. section 5.1.3
Choose requests from observed usage, then check the trade-offs:
- Start with a generously requested Pod. Use `kubectl top pods` to observe startup usage, then apply representative load and observe usage over time. Reduce the initial requests once you understand what the Pod needs. section 5.2
- Set memory requests above the amount needed to start and run, with a buffer. Memory shortages can terminate a container; do not rely on unused node memory for a known need. section 5.2.1
- Use steady-state CPU demand as a starting point. Too little CPU generally slows the application rather than crashing it; a higher limit can allow bursts, though performance may vary by node. section 5.2.2
A low-traffic website fleet
Hundreds of mostly idle sites could each request `50m` CPU while allowing a `1000m` limit. This fits more Pods onto each core and lets active sites burst. It saves capacity only while their peaks rarely coincide; simultaneous demand can degrade performance. Request enough CPU for a reasonable base load rather than depending on bursts. section 5.2.3
