Resource bursting lets a Pod temporarily use more computing capacity than its normal request when spare capacity exists on the node. Requests reserve the amount used for scheduling; limits bound usage after the Pod starts. section 5.1.1
Kubernetes applies bursting with these operational consequences:
- The scheduler places Pods using requests, not limits. section 5.1.1
- A container may consume available capacity up to its limits after scheduling. section 5.1.1
- Exceeding a memory limit restarts the Pod, while exceeding a CPU limit causes throttling. section 5.1.1
- During contention, Pods using more than their memory request may be evicted, and those exceeding their CPU request may be throttled to the requested amount. section 5.1.1
- Overcommitting spare capacity can improve resource efficiency but introduces performance variability. section 5.3
Bounded burst capacity
A container requesting 200m CPU and 250Mi memory can burst to a limit of 300m CPU and 400Mi memory when capacity is available. The request guides placement; the limits constrain runtime use. 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.
Inspect a Deployment manifest that sets CPU and memory requests alongside higher runtime limits. section 5.1.1
