Chapter 2 of 6 · 5 practices · 5 min · 4-question quiz
Resource requests, limits and scaling
How to tell the scheduler what each container needs, which limits help and which hurt, and how requests feed autoscaling.
Start: Set CPU and memory requests on every container5 practices in this chapter
- 1Set CPU and memory requests on every containerThe scheduler places a Pod only on a node whose unreserved capacity covers the sum of its containers' requests. Limits play no part in placement. Without requests, the scheduler treats the Pod as…
- 2Set a memory limit, and keep it equal to the requestMemory cannot be throttled. When a container uses more than its memory limit, the kernel may end it with an out-of-memory (OOM) kill. When a node runs out of memory, the kubelet evicts Pods to…
- 3Be deliberate about CPU limitsCPU is different from memory. A container that reaches its CPU limit is throttled, not killed: the kernel slows it down. That protects neighbours, but it also means a container can be slow while the…
- 4Scale replicas with a HorizontalPodAutoscaler, based on requestsA HorizontalPodAutoscaler (HPA) adds and removes replicas to keep a metric near a target. For CPU and memory, the target is a percentage of the request, so an HPA on a Deployment with no requests…
- 5Give each namespace a ResourceQuota and default requestsOne runaway Deployment that scales to hundreds of replicas can starve every other team on the cluster. A ResourceQuota caps the total requests, limits and object counts a namespace can use, and a…
Check yourself on this chapter
4 questions, right here once you are signed in. Your progress is saved as you read.