Defining Pod Resource Requests and Limits

You will configure CPU and memory constraints to ensure the scheduler makes informed decisions about node capacity and application performance requirements.

In this lesson, you will learn how to stabilize your Kubernetes cluster by defining exactly how much CPU and memory your Pods need to operate safely.

When you deploy a Pod without resource constraints, Kubernetes treats it as having unlimited potential. This creates a risk: if one container starts consuming all available memory on a Node, it can trigger an "Out of Memory" (OOM) event that crashes every other application running on that same server. To prevent this, we use Requests and Limits.

Requests vs. Limits

Requests are the "guaranteed" minimum. When the Scheduler places a Pod, it looks for a Node with enough free capacity to satisfy these requests. If you request 256Mi of memory, Kubernetes ensures your Pod has at least that much dedicated to it.
Limits are the "hard ceiling." If your application tries to exceed its memory limit, Kubernetes will terminate the container. If it tries to exceed its CPU limit, the container will be throttled (slowed down) to stay within the allowed threshold.

Defining Resources in YAML

You define these constraints within the resources block of your container specification:

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

In this example, the unit 250m represents "millicores" (0.25 of a CPU core). By setting these, you provide the Scheduler with the data it needs to place your workload on an appropriate Node, and you provide the Kubelet with the enforcement rules necessary to protect the Node’s overall health. Without these, your Pods are "BestEffort" workloads, which are the first to be evicted if a Node runs low on resources.

Key Takeaway: Resource requests help the Scheduler place your Pods effectively, while limits provide the necessary boundaries to prevent single Pods from impacting the stability of the entire Node.