Resource Requests and Limits

Introduction: Why Resource Management Matters

Imagine you're running a production Kubernetes cluster with dozens of applications. One day, a developer deploys a new service that has a memory leak. Within minutes, this single container consumes all available memory on its node, causing the operating system to kill random processes to free up space. Suddenly, your database, web servers, and monitoring tools all crash simultaneously. This catastrophic scenario happens more often than you'd think, and it's exactly why resource requests and limits exist. In this lesson, you'll learn how to configure these settings so that the Kubernetes scheduler places your pods on appropriate nodes and prevents any single container from monopolizing resources and destabilizing the entire system.

What Are Requests and Limits?

When you deploy a pod to Kubernetes, you can specify two types of resource constraints: requests and limits . These work together but serve different purposes. A resource request tells the Kubernetes scheduler the minimum amount of CPU and memory your container needs to function properly. Think of this as making a reservation — when you book a hotel room for two people, the hotel needs to guarantee space for at least two people. The scheduler uses requests to decide which node has enough available resources to run your pod. If no node can satisfy the request, your pod stays in a Pending state until resources become available. A resource limit, on the other hand, sets the maximum amount of CPU and memory your container is allowed to consume. Continuing the hotel analogy, the limit is like the maximum occupancy of the room — even if you reserved space for two people, the fire code might allow up to four people maximum. Kubernetes enforces limits at runtime: if your container tries to use more memory than its limit, it gets killed and restarted. If it tries to use more CPU than its limit, it gets throttled (slowed down) but not killed. Limits protect your nodes from being overwhelmed by a single misbehaving container.

Understanding Resource Units

Understanding how to measure these resources is crucial. CPU is measured in cores, where one core represents one physical CPU core or one virtual core on a cloud instance. Kubernetes allows you to specify fractional cores using millicores (m). For example, 100m means 0.1 cores or 10% of one CPU core. If you request 500m, you're asking for half a core. You can also use decimal notation: 0.5 is equivalent to 500m. Most applications don't need an entire core, so millicores give you fine-grained control. Memory is measured in bytes, but writing large numbers like 134217728 bytes is impractical. Instead, Kubernetes supports suffixes that make these values readable. The suffix Mi stands for mebibytes (1 Mi = 1,048,576 bytes), and Gi stands for gibibytes (1 Gi = 1,024 Mi). You might also see M and G for decimal megabytes and gigabytes, but the binary versions (Mi, Gi) are more common in Kubernetes. For example, 128Mi means 128 mebibytes of memory, which is roughly 134 megabytes. When choosing memory values, think about what your application actually needs: a simple web server might need only 128Mi, while a database might need 2Gi or more.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Declaring Resource Requests and Limits in Deployments

Let's build a deployment that includes resource requests and limits. This configuration will ensure our nginx web server gets scheduled appropriately and can't consume excessive resources. We'll start with the basic deployment structure you learned in the previous lesson, then add the resource specifications. Here's the beginning of our deployment:

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-resources
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-app

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-resources
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web-app

This should look familiar — we're creating a deployment called web-app-resources that will run two replicas of our application. The selector tells the deployment which pods it manages. Now comes the important part: defining the pod template with resource specifications. Let's add the template section:

YAML

  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: nginx
          image: nginx:1.25

  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: nginx
          image: nginx:1.25

So far, this is standard: we're defining a container named nginx using the nginx:1.25 image. Now we'll add the resources section, which is where we declare our requests and limits:

YAML

          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

The resources field goes inside the container definition because each container in a pod can have different resource requirements. Under resources, we define two subsections: requests and limits. The requests section tells the scheduler: "This container needs at least 100 millicores of CPU and 128 mebibytes of memory to run." When the scheduler looks for a node to place this pod, it will only consider nodes that have at least these amounts available.

The limits section sets the boundaries: "This container is allowed to use up to 500 millicores of CPU and 256 mebibytes of memory." If the nginx process tries to allocate more than 256Mi of memory, Kubernetes will kill the container and restart it. If it tries to use more than 500m CPU, Kubernetes will throttle it, preventing it from consuming more CPU cycles. These limits protect other pods running on the same node from resource starvation.

Notice that we've set the CPU limit to 5x the request (500m vs. 100m) but only doubled the memory limit (256Mi vs. 128Mi). This is a common pattern: CPU is a compressible resource (the application just runs slower if throttled), while memory is not compressible (if you run out, the application crashes). Being more conservative with memory limits reduces the chance of your container being killed. You might wonder what values to use initially — start conservatively based on your application's documentation or similar deployments, then adjust based on monitoring.

Save this complete configuration as deployment-resources.yaml. You now have a deployment that explicitly declares its resource requirements, making it much more predictable and reliable than a deployment without resource specifications. Without these settings, the scheduler has no idea how much capacity your pod actually needs, and your container could theoretically consume all available resources on its node.

Applying and Verifying Your Configuration

Let's deploy this resource-managed application to your cluster. Apply the deployment using kubectl:

Shell

kubectl apply -f deployment-resources.yaml

kubectl apply -f deployment-resources.yaml

You should see output confirming the deployment was created:

text

deployment.apps/web-app-resources created

deployment.apps/web-app-resources created

This command sends your deployment configuration to the Kubernetes API server, which then creates the deployment object. The deployment controller immediately starts working to create the two replica pods you specified. Now, let's verify that the pods were successfully created and are running:

Shell

kubectl get pods -l app=web-app

kubectl get pods -l app=web-app

The -l app=web-app flag filters the results to show only pods with the label app=web-app. You should see output like this:

text

NAME                                  READY   STATUS    RESTARTS   AGE
web-app-resources-7d4b6c9f8d-k7m2x   1/1     Running   0          45s
web-app-resources-7d4b6c9f8d-p9n4k   1/1     Running   0          45s

NAME                                  READY   STATUS    RESTARTS   AGE
web-app-resources-7d4b6c9f8d-k7m2x   1/1     Running   0          45s
web-app-resources-7d4b6c9f8d-p9n4k   1/1     Running   0          45s

Both pods show STATUS: Running, which means they were successfully scheduled on nodes and started. The READY column shows 1/1, indicating that one out of one container in each pod is ready. If you had seen STATUS: Pending, it might indicate that no node has enough resources to satisfy your requests. In that case, you'll need to either add more nodes to your cluster or reduce your resource requests.

Now let's inspect one of these pods in detail to confirm that our resource requests and limits were actually applied. Copy one of the pod names from the output above (you'll use your actual pod name, not the example shown here) and run:

Shell

kubectl describe pod web-app-resources-7d4b6c9f8d-k7m2x

kubectl describe pod web-app-resources-7d4b6c9f8d-k7m2x

The describe command provides extensive information about the pod. You'll see many sections, but we're particularly interested in the resource specifications. Look for a section that shows the container details — it will look something like this:

text

Containers:
  nginx:
    Container ID:   docker://abc123...
    Image:          nginx:1.25
    Port:           <none>
    State:          Running
    Ready:          True
    Limits:
      cpu:     500m
      memory:  256Mi
    Requests:
      cpu:        100m
      memory:     128Mi

Containers:
  nginx:
    Container ID:   docker://abc123...
    Image:          nginx:1.25
    Port:           <none>
    State:          Running
    Ready:          True
    Limits:
      cpu:     500m
      memory:  256Mi
    Requests:
      cpu:        100m
      memory:     128Mi

This output confirms that Kubernetes applied exactly the resource specifications we defined. The Requests section shows that the scheduler reserved 100m CPU and 128Mi memory on the node for this pod. The Limits section shows that the container cannot exceed 500m CPU and 256Mi memory. You can use the grep command to extract just this information if you don't want to scroll through all the describe output:

Shell

kubectl describe pod web-app-resources-7d4b6c9f8d-k7m2x | grep -A5 "Requests\|Limits"

kubectl describe pod web-app-resources-7d4b6c9f8d-k7m2x | grep -A5 "Requests\|Limits"

This command searches for lines containing "Requests" or "Limits" and shows 5 lines after each match, giving you a focused view of the resource settings. The output will look like:

text

    Limits:
      cpu:     500m
      memory:  256Mi
    Requests:
      cpu:        100m
      memory:     128Mi

    Limits:
      cpu:     500m
      memory:  256Mi
    Requests:
      cpu:        100m
      memory:     128Mi

If these values don't match what you specified in your YAML file, that would indicate a problem with your configuration. In our case, everything matches perfectly, confirming that your deployment is correctly configured with resource management.

Checking Resource Usage with kubectl top

Knowing what resources you've requested and limited is important, but understanding what your containers actually use is equally crucial. Kubernetes provides the top command to show real-time resource consumption. Let's start by looking at resource usage across all nodes in your cluster:

Shell

kubectl top nodes

kubectl top nodes

This command queries the metrics server (which comes pre-installed on CodeSignal's environment) and shows current resource consumption for each node. You'll see output like:

text

NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
minikube   150m         7%     1200Mi          30%

NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
minikube   150m         7%     1200Mi          30%

The output shows that your node is currently using 150m (0.15 cores) of CPU, which represents 7% of the node's total CPU capacity. The memory usage is 1200Mi out of the node's total capacity, representing 30% utilization. These numbers include all pods running on the node, including system pods. If you're running a multi-node cluster, you'll see one row per node, helping you identify if any nodes are overloaded.

Now let's zoom in to see the resource usage of individual pods:

Shell

kubectl top pods

kubectl top pods

This shows the current CPU and memory consumption for each pod:

text

NAME                                  CPU(cores)   MEMORY(bytes)
web-app-resources-7d4b6c9f8d-k7m2x   1m           10Mi
web-app-resources-7d4b6c9f8d-p9n4k   1m           11Mi

NAME                                  CPU(cores)   MEMORY(bytes)
web-app-resources-7d4b6c9f8d-k7m2x   1m           10Mi
web-app-resources-7d4b6c9f8d-p9n4k   1m           11Mi

Each nginx pod is using approximately 1m CPU (one millicore) and around 10Mi memory. These numbers represent what the containers are currently consuming right now. The top command gives you a snapshot of resource usage at this moment, helping you understand whether your pods are using more or less than you anticipated.

Right-Sizing Resources Based on Usage

Look at the usage numbers carefully and compare them to what we requested: we asked for 100m CPU and 128Mi memory per pod, but our pods are using only 1m CPU and about 10Mi memory. Our pods are using only 1% of the CPU we requested and less than 10% of the memory we requested. This reveals an important insight: we over-provisioned our resources. The scheduler reserved space for 100m CPU per pod, but the pods are barely using any CPU.

Understanding the difference between these three concepts is critical: requests are what the scheduler reserves on the node, limits are the maximum the container can use, and actual usage is what the container is currently consuming. In an ideal world, your actual usage should stay comfortably between your requests and limits. If usage is consistently much lower than requests (like our example), you're wasting cluster capacity. If usage frequently hits the limits, your application might be getting throttled or killed, indicating you should increase the limits.

Let's say you monitored these pods over several days and noticed the CPU usage never exceeded 10m and memory never exceeded 50Mi. You might adjust your resource specifications to be more accurate:

YAML

resources:
  requests:
    cpu: "20m"      # Increased from 10m to allow some headroom
    memory: "64Mi"  # Increased from 50Mi to allow headroom
  limits:
    cpu: "100m"     # Reduced from 500m
    memory: "128Mi" # Reduced from 256Mi

resources:
  requests:
    cpu: "20m"      # Increased from 10m to allow some headroom
    memory: "64Mi"  # Increased from 50Mi to allow headroom
  limits:
    cpu: "100m"     # Reduced from 500m
    memory: "128Mi" # Reduced from 256Mi

This tuning process — deploy, monitor, adjust — is how you find the right balance between resource efficiency and reliability. You deploy your application with initial estimates, monitor the actual usage over time, and then adjust the requests and limits based on what you observe.

Introduction: Why Resource Management Matters

What Are Requests and Limits?

Understanding Resource Units

Join the 1M+ learners on CodeSignal

Configuring Requests and Limits Together

Declaring Resource Requests and Limits in Deployments

Applying and Verifying Your Configuration

Checking Resource Usage with kubectl top

Right-Sizing Resources Based on Usage

Summary: Building Reliable Applications