Resource allocation and consumption mainly in terms of CPU and Memory in Kubernetes is challenging to configure. This article delves into the Kubernetes objects ResourceQuota and LimitRange and how they are used with requests and limits. These objects and configurations help to ensure efficient resource utilization and allocation within the cluster among various namespaces and teams.

ResourceQuota

It is a Kubernetes object defined at the namespace level. ResourceQuota limits the total resource consumption by the entities within the namespace level. Limitations depend on CPU, memory, number of pods, PVCs, etc.

ResourceQuota can be created for each namespace according to the needs and demands of the teams. When a user creates resources within the namespace, the quota system tracks and checks the usage and values defined on the ResourceQuota to decide whether to allow the creation of a resource. Below is the sample ResourceQuota YAML manifest:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-quota
  namespace: testing
spec:
  hard:
    pods: "3"                   # Limit the total number of pods to 3
    requests.cpu: "2"           # Total CPU requested across all pods cannot exceed 2 core
    requests.memory: "2Gi"      # Total memory requested across all pods cannot exceed 2 GiB
    limits.cpu: "4"             # Total CPU limit across all pods cannot exceed 4 cores
    limits.memory: "4Gi"        # Total memory limit across all pods cannot exceed 4 GiB
    persistentvolumeclaims: "3" # Limit the total number of PersistentVolumeClaims to 3

When ResourceQuota with CPU and Memory is defined, users must specify the requests and limits for those values.

Now,
What happens when some pod uses all the resources within the namespace?
What happens if we need to provide the default values to the entities within the namespace?
Kubernetes has a policy called LimitRange.

LimitRange

It is a Kubernetes object and policy defined for each Pod, Container, and Persistent Volume Claim within a namespace. It enforces limits on the CPU or memory usage per pod or container and applies defaults if they are not set.

LimitRange prevents resource overuse at the container or pod level by defining min, max, default, and defaultRequest for CPU/memory.

If the LimitRange defines default and/or defaultRequest values, no need to specify resource requests/limits explicitly during resource deployment. Kubernetes will automatically apply the default values from the LimitRange to the containers in your Pods.

If the LimitRange does not define default or defaultRequest values, you must explicitly specify resources.requests and/or resources.limits in your deployment YAML.
Below is the sample LimitRange YAML manifest:

apiVersion: v1
kind: LimitRange
metadata:
  name: limit-range
  namespace: testing
spec:
  limits:
  - type: Container
    default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "200m"
      memory: "256Mi"
    min:
      cpu: "100m"
      memory: "128Mi"
    max:
      cpu: "1"
      memory: "1Gi"
  - type: Pod
    min:
      cpu: "200m"
      memory: "256Mi"
    max:
      cpu: "2"
      memory: "2Gi"

Request and Limits

It is a configuration for individual containers at a pod level. Request Limits are set in collaboration with ResourceQuota and LimitRange for better resource utilization and limitations within the Kubernetes Cluster. Request limits are defined with two values:
Request: The minimum amount of resources guaranteed to the container (used for scheduling decisions).
Limit: The maximum resources the container can use (enforced at runtime).

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: demo-container
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "200m"
      limits:
        memory: "512Mi"
        cpu: "500m"

References:

ResourceQuota, LimitRange, Requests and Limits

Table of contents

ResourceQuota

LimitRange

Request and Limits

Subscribe to my newsletter

DeepEnc

DeepEnc