Kubernetes Resource Requests and Limits: A Practical Guide

Previously in this course, we discussed how to ensure your application stays healthy using liveness probes. While probes handle health checks, they don't prevent a single container from hogging all the node's CPU or RAM. In this lesson, we add the final layer of stability: defining strict resource usage boundaries for your applications.

Understanding Resources: The "Noisy Neighbor" Problem

By default, a Kubernetes Pod has no limits on the CPU or memory it can consume. If a container starts a memory-intensive process and leaks, it will consume all available RAM on the host node, potentially causing the Kubelet or other critical system processes to crash.

To prevent this, we use two concepts: Requests and Limits.

• Requests: The minimum amount of CPU and memory the container is guaranteed. The scheduler uses this value to decide which node has enough "room" to place your Pod.
• Limits: The maximum amount of CPU and memory the container is allowed to consume. If a container attempts to exceed its memory limit, it is terminated.

Configuring Your First Resource Manifest

Let's update our web app manifest to include these constraints. We define resources within the containers section of our Pod specification.

YAML
apiVersion: v1
kind: Pod
metadata:
  name: resource-demo-pod
spec:
  containers:
  - name: web-app
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Understanding the Units

• CPU: Measured in "millicores" (m). 250m means 0.25 of a single CPU core.
• Memory: Measured in bytes. You can use standard suffixes like Mi (Mebibytes) or Gi (Gibibytes).

Why Containers Get "OOMKilled"

When you see a Pod status of OOMKilled (Out of Memory Killed), it means your container hit its memory limit. The Linux kernel's OOM killer stepped in and terminated the process to protect the rest of the node.

This is a hard stop. Unlike CPU throttling—where a process just runs slower because it hit its limit—exceeding a memory limit results in the container crashing immediately. If you see this error, you need to either increase your memory limit or investigate your application for memory leaks.

Hands-on Exercise

Apply the manifest above to your cluster using kubectl apply -f manifest.yaml. Once it is running, verify the resource configuration:

1. Run kubectl describe pod resource-demo-pod.
2. Look for the Containers -> web-app -> Limits and Requests sections to confirm your settings are active.
3. Challenge: Try changing the limits to a tiny value like 4Mi. Watch the Pod status change to OOMKilled or CrashLoopBackOff as it fails to start.

Common Pitfalls

• Setting Limits Equal to Requests: This creates "Guaranteed" Quality of Service (QoS). It's great for production databases, but it prevents the Pod from utilizing "burst" capacity during traffic spikes.
• Omitting Requests: If you don't set requests, the scheduler might place your Pod on an already overloaded node, leading to performance degradation.
• Misunderstanding CPU Throttling: If you set a low CPU limit, your app won't crash, but it will feel sluggish. Always check your application's latency metrics before lowering CPU limits.

FAQ

Does setting a high limit hurt performance? No, limits are ceilings, not reservations. Setting a high limit just gives your container permission to use more hardware if it's available.

What happens if I don't set any resources? Your container will be classified as "BestEffort." These are the first pods to be evicted by the node if it runs out of memory. Always define resources for production workloads.

Recap

We’ve learned that resource management is essential for cluster health. By defining requests, we help the scheduler place pods intelligently, and by defining limits, we protect the node from runaway processes. When a container exceeds its memory limit, the OOMKilled error serves as a signal that your resource boundaries need adjustment.

Up next, we will explore Using Secrets to handle sensitive configuration data securely.