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

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

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"

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

You should see output confirming the deployment was created:

text

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

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

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

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

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"

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

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.

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