A Pod may have enough resources when it starts but face competition for memory later. Kubernetes assigns it a quality of service (QoS) class from its containers’ resource requests and limits. The class describes its resource guarantees and helps determine what happens under contention. section 5.1.2 section 5.3
There are three classes:
- Guaranteed: Every container has limits equal to requests. The Pod has the resources it requested and is not evicted because of resource contention. section 5.1.2
- Burstable: The Pod does not qualify as guaranteed, but at least one container has a request. It can use spare resources beyond its request, so performance may change when that spare capacity disappears. Memory use above its request can expose it to eviction. section 5.1.2
- Best effort: No container has requests or limits. The Pod has no requested allocation to protect it; this is the lowest class. section 5.1.2 section 5.1.3
Choosing between a guarantee and a burst
Suppose a container requests 200m CPU and 250Mi memory but has limits of 300m CPU and 400Mi memory. Its Pod is burstable: it can use the extra capacity when available, but should not depend on always having it. Setting each limit equal to its corresponding request instead makes this single-container Pod guaranteed. section 5.1.1 section 5.1.2
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 manifest places CPU and memory requests and limits under the container’s resources field. The higher limits illustrate a burstable configuration. section 5.1.1
QoS matters most when resources run short. For Pods using more than their requests, Kubernetes considers priority and then the amount of excess use when choosing evictions; at equal priority, best-effort Pods are first. A repeatedly Evicted Pod may need larger requests or more cluster capacity. A Pod that exceeds its memory limit is restarted, while one that exceeds its CPU limit is throttled. section 5.1.3 section 5.1.1
