Skip to content

Kubernetes resource Request

In Kubernetes, a resource Request is the amount of computing resources (CPU and Memory) that a container is guaranteed to receive^[400-devops__06-Kubernetes__k8s-ithelp__Day21__README.md]. It represents the minimum resource requirement for a container and serves as the basis for Kubernetes scheduler decisions when assigning Pods to nodes^[400-devops__06-Kubernetes__k8s-ithelp__Day21__README.md].

Function and Scheduling

The primary function of the request value is to determine where a Pod can be deployed. A Pod is only scheduled to run on a node if the node has enough unallocated resources to satisfy the Pod's request value^[400-devops__06-Kubernetes__k8s-ithelp__Day21__README.md].

Mathematically, a valid request must be greater than or equal to 0 and cannot exceed the total allocatable capacity of the node^[400-devops__06-Kubernetes__k8s-ithelp__Day21__README.md].

0 <= request <= Node Allocatable

Relationship to Limits

Requests are part of a resource management pair that includes Limits. The request defines the guaranteed minimum, while the limit defines the maximum usage allowed^[400-devops__06-Kubernetes__k8s-ithelp__Day21__README.md].

The relationship between these two values follows a specific rule: the limit must be greater than or equal to the request^[400-devops__06-Kubernetes__k8s-ithelp__Day21__README.md].

request <= limit <= Infinity

If a limit is not specified or set to 0, the container may consume resources up to the available capacity of the node^[400-devops__06-Kubernetes__k8s-ithelp__Day21__README.md].

Impact on Quality of Service (QoS)

The configuration of requests (and limits) directly determines the Quality of Service (QoS) class assigned to a Pod. This class influences the Pod's priority and stability when the cluster is under resource pressure^[400-devops__06-Kubernetes__k8s-ithelp__Day21__README.md].

  • Guaranteed: If a Pod's request equals its limit for both CPU and Memory, it receives the highest priority. These Pods are rarely killed unless they exceed their limits or no lower-priority Pods remain^[400-devops__06-Kubernetes__k8s-ithelp__Day21__README.md].
  • Burstable: If a Pod has a request set but it is lower than the limit (or no limit is set), it falls into this class. These Pods have a minimum resource guarantee but can use more if available^[400-devops__06-Kubernetes__k8s-ithelp__Day21__README.md].
  • BestEffort: If no request or limit is set, the Pod is BestEffort. These have the lowest priority and are the first to be terminated if the node runs out of memory^[400-devops__06-Kubernetes__k8s-ithelp__Day21__README.md].

Setting a limit higher than a request allows a Pod to utilize spare resources when the node is idle, while still ensuring a baseline during contention^[400-devops__06-Kubernetes__k8s-ithelp__Day21__README.md].

Sources

  • 400-devops__06-Kubernetes__k8s-ithelp__Day21__README.md