Managing Container Resources in Pods

1. Why We Need Resource Management

Before diving into the YAML, it's essential to understand the "why." What problems do resource requests and limits solve? In short, they bring predictability and stability to your cluster.

• Requests are about scheduling. They guarantee that your Pod will have the minimum resources it needs to run. The Kubernetes scheduler uses this information to find a node with enough available capacity.
• Limits are about runtime enforcement. They prevent a container from consuming more than its allocated share of resources, protecting the node and other workloads from a single "noisy neighbor."

The following video provides an excellent analogy, comparing resource management to personal budgeting, and explains the core problems solved by this mechanism.

This diagram provides a great visual summary of how these concepts fit together on a node.

2. Configuring Requests and Limits in a Pod Manifest

Now, let's see how to implement this in a manifest. Resource requests and limits are defined within the spec of a container, inside a resources block.

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

To properly configure these values, you must understand the units Kubernetes uses.

Key Points on Units:

• CPU: Measured in "Kubernetes CPUs." 1 equals one physical or virtual core. You will most often use millicpus, written as 100m (100 millicpus = 0.1 CPU).
• Memory: Measured in bytes. It's crucial to use the correct suffix. 100m of memory is 0.1 bytes (a common mistake!), whereas 100Mi is 100 mebibytes. For clarity and consistency, always use the Mi or Gi suffixes for memory.

resources:
  requests:
    cpu: "1.5"
    memory: "2G"
  limits:
    cpu: "2"
    memory: "4G"

resources:
  requests:
    cpu: "1500m"
    memory: "2Gi"
  limits:
    cpu: "2000m"
    memory: "4Gi"

resources:
  requests:
    cpu: "150m"
    memory: "2Mi"
  limits:
    cpu: "200m"
    memory: "4Mi"

3. Enforcement: What Happens When Limits Are Reached?

Defining requests and limits is only half the story. As a Platform Engineer, you need to know what happens when a container misbehaves. Kubernetes enforces CPU and memory limits differently.

• CPU Limit: If a container tries to use more CPU than its limit, it will be throttled. It won't be killed, but its performance will be artificially capped, slowing it down.
• Memory Limit: If a container tries to allocate memory beyond its limit, it will be terminated by the operating system. You will see the Pod's status as OOMKilled (Out Of Memory Killed), and Kubernetes will likely restart it.

The following video demonstrates these scenarios practically. It shows what happens when a Pod operates within its limits, what happens when it exceeds its memory limit, and what happens when it requests more resources than any node can provide.

When you encounter these issues, kubectl describe pod <pod-name> is your best friend. As shown in the video and the official documentation's troubleshooting section, the "Events" section at the bottom of the output will tell you exactly why a Pod is Pending or why it was last terminated.

4. Quality of Service (QoS) Classes

Based on the requests and limits you set, Kubernetes automatically assigns one of three Quality of Service (QoS) classes to your Pod. This class determines how Kubernetes prioritizes your Pod, especially when a node is under pressure and needs to evict Pods to reclaim resources.

1. Guaranteed: Highest priority. Assigned when requests and limits are set and are equal for both CPU and memory on all containers. These Pods are the last to be killed.
2. Burstable: Medium priority. Assigned when requests and limits are set, but they are not equal for at least one resource. These Pods can "burst" to use more resources up to their limit if available.
3. BestEffort: Lowest priority. Assigned when no requests or limits are set at all. These are the first Pods to be evicted when a node is low on resources.

Understanding these classes is important for designing resilient systems. Critical system components should run with a Guaranteed QoS.

As a best practice, avoid running production workloads with the BestEffort QoS class. Always define requests to ensure your application gets the resources it needs. For memory, it's often recommended to set the request and limit to the same value (Guaranteed QoS for memory) to create the most predictable behavior. The use of CPU limits is more debated, as throttling can sometimes hide performance issues, but they are a useful tool for preventing noisy neighbors.

Conclusion

You have now equipped your Pods with one of the most critical features for production readiness: resource management. By setting requests and limits, you are providing essential information to Kubernetes that enables it to be a more effective orchestrator.

Key Takeaways:

• Requests are minimum guarantees used for scheduling.
• Limits are maximum caps enforced at runtime.
• Exceeding a CPU limit leads to throttling.
• Exceeding a memory limit leads to an OOMKilled termination.
• Resource settings determine a Pod's QoS class (Guaranteed, Burstable, BestEffort), which affects its eviction priority.
• Always use explicit units like m for CPU and Mi/Gi for memory.

Our Pod is now more robust. It has a defined resource profile. But what if the application inside the container crashes or becomes unresponsive, even while staying within its resource limits? Kubernetes wouldn't know anything is wrong. In our next lesson, we will solve this by configuring liveness and readiness probes, which allow Kubernetes to check the health of the actual application.