Kubernetes 1.37 Pod Resources: Testing CPU and Memory Allocation

Kubernetes resource requests and limits are often treated as simple configuration values, but they directly influence how workloads are scheduled and how containers behave under resource pressure.

A pod can request CPU and memory from the cluster and optionally define limits for how much it is allowed to consume.

For example:

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

These values affect scheduling, runtime behavior, and resource isolation.

When evaluating a Kubernetes upgrade or tuning workloads, developers should test whether the configured resources match actual application requirements rather than relying on default values.

Understanding CPU and Memory Requests

A resource request tells Kubernetes how much resource a container expects to need.

For example:

resources:
  requests:
    cpu: "500m"
    memory: "512Mi"

This means the scheduler considers the pod's requested resources when selecting a node.

CPU is generally expressed in millicores:

1000m = 1 CPU
500m  = 0.5 CPU
250m  = 0.25 CPU

Memory is normally expressed using units such as:

128Mi
256Mi
512Mi
1Gi

Requests are important because Kubernetes uses them when determining whether a node has sufficient allocatable capacity.

Understanding Resource Limits

A limit defines the maximum resource consumption allowed for a container.

For example:

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"

  limits:
    cpu: "1"
    memory: "512Mi"

Here, the workload requests:

250 millicores of CPU
256 MiB of memory

while its configured limits are:

1 CPU
512 MiB of memory

Requests and limits serve different purposes and should not automatically be set to the same value.

CPU and Memory Behave Differently

One of the most important concepts is that CPU and memory are handled differently.

CPU is a compressible resource.

If a container reaches its CPU limit, Kubernetes can throttle its CPU usage.

Memory is different.

If a container exceeds its memory limit and the system cannot reclaim enough memory, the container can be terminated due to an out-of-memory condition.

Conceptually:

CPU
 |
 +-- Usage exceeds limit
       |
       v
   Throttling

Memory
 |
 +-- Usage exceeds available limit
       |
       v
   Possible OOM termination

This difference is critical when configuring production workloads.

Creating a Test Pod

A simple resource-testing pod can be defined as:

apiVersion: v1
kind: Pod
metadata:
  name: resource-test
spec:
  containers:
    - name: app
      image: nginx
      resources:
        requests:
          cpu: "250m"
          memory: "256Mi"
        limits:
          cpu: "1"
          memory: "512Mi"

Apply it with:

kubectl apply -f resource-test.yaml

Then verify:

kubectl get pod resource-test

Inspecting Allocated Resources

Use:

kubectl describe pod resource-test

Look for the container's resource configuration.

You can also retrieve the complete configuration:

kubectl get pod resource-test -o yaml

This is useful when troubleshooting because the live Kubernetes object may differ from the configuration file you believe was deployed.

Checking Node Capacity

Before testing resource allocation, inspect the node:

kubectl describe node <node-name>

Important values include:

Capacity
Allocatable
Allocated resources

A node might have:

CPU Capacity:       8
CPU Allocatable:    7.5
Memory Capacity:    32Gi
Memory Allocatable: 30Gi

The distinction between capacity and allocatable resources matters because not all node resources are available for application pods.

Checking Actual Usage

For clusters with the appropriate resource metrics available, use:

kubectl top pods

For a particular namespace:

kubectl top pods -n production

Node usage can be checked with:

kubectl top nodes

These commands help compare configured resources with actual consumption.

For example:

NAME        CPU(cores)   MEMORY(bytes)
api-pod     180m         210Mi
worker      750m         420Mi

This provides a starting point for deciding whether requests and limits are reasonable.

Testing CPU Allocation

Create a workload that intentionally consumes CPU.

For example:

apiVersion: v1
kind: Pod
metadata:
  name: cpu-test
spec:
  containers:
    - name: cpu
      image: busybox
      command:
        - sh
        - -c
        - |
          while true; do
            : 
          done
      resources:
        requests:
          cpu: "100m"
        limits:
          cpu: "500m"

The process continuously performs work, allowing you to observe CPU behavior.

Monitor it:

kubectl top pod cpu-test

The exact observed CPU usage depends on the node, runtime, competing workloads, and resource configuration.

CPU Throttling

Suppose a container has:

limits:
  cpu: "500m"

and attempts to consume more CPU than that.

The container does not normally receive unlimited CPU simply because the node has spare capacity. Its CPU usage can be constrained according to the configured limit.

This can become important for latency-sensitive services.

A workload that repeatedly hits its CPU limit may experience:

Increased response latency
Lower throughput
Longer processing times
Queue buildup

Therefore, CPU limits should be evaluated against actual workload behavior.

Testing Memory Allocation

Memory should be tested separately.

For example:

apiVersion: v1
kind: Pod
metadata:
  name: memory-test
spec:
  containers:
    - name: memory
      image: polinux/stress
      args:
        - --vm
        - "1"
        - --vm-bytes
        - "400M"
        - --vm-hang
        - "1"
      resources:
        requests:
          memory: "256Mi"
        limits:
          memory: "512Mi"

The purpose of this type of test is to observe how the workload behaves when memory consumption approaches its configured limit.

Do not run memory stress tests against production workloads.

Use an isolated development or test namespace.

Observing OOM Conditions

If a container exceeds its available memory and is terminated, inspect the pod:

kubectl describe pod memory-test

You may see an indication that the container was terminated because of an out-of-memory condition.

You can also check:

kubectl get pod memory-test -o wide

and:

kubectl get pod memory-test \
  -o jsonpath='{.status.containerStatuses[*].lastState}'

The exact output depends on the workload and cluster state.

Requests Affect Scheduling

Suppose a node has:

Allocatable CPU: 4

and four pods each request:

cpu: 1

Those requests can consume the node's schedulable CPU capacity.

A fifth pod requesting:

requests:
  cpu: "1"

may need to be placed on another node if sufficient allocatable capacity is unavailable.

This is why excessively high requests can create scheduling problems even when applications rarely use that amount of CPU.

Overcommitting Resources

Kubernetes allows workloads to request resources while potentially using more or less than their requests, depending on configuration and available node capacity.

Consider:

Pod A
Request: 1 CPU
Actual: 200m

Pod B
Request: 1 CPU
Actual: 150m

Pod C
Request: 1 CPU
Actual: 300m

The cluster may have substantial unused CPU despite the combined requests being much higher than actual consumption.

This is one reason resource sizing should be based on measured workload behavior.

However, aggressive overcommitment can increase contention during traffic spikes.

Comparing Requests and Actual Usage

A useful review table looks like this:

Resource	Configured Request	Configured Limit	Typical Usage
CPU	250m	1 CPU	150m
Memory	256Mi	512Mi	220Mi

This workload appears to have some headroom.

A different workload might show:

Resource	Configured Request	Configured Limit	Typical Usage
CPU	250m	1 CPU	900m
Memory	256Mi	512Mi	480Mi

That workload is frequently approaching its limits and deserves closer investigation.

Resource Quality of Service

Kubernetes assigns pods a QoS class based on their resource configuration.

Common classes include:

Guaranteed
Burstable
BestEffort

For example, a pod with matching CPU and memory requests and limits for all containers can qualify for the Guaranteed class.

A pod with some resource requests or limits but not matching values generally falls into the Burstable class.

A pod without CPU and memory requests or limits can fall into BestEffort.

QoS classification can become relevant when a node experiences resource pressure.

Common Mistakes

Setting Requests Too Low

Very low requests can cause the scheduler to pack too many workloads onto a node.

Setting Requests Too High

Excessively high requests can leave cluster capacity unusable from the scheduler's perspective.

Treating CPU and Memory the Same

CPU can be throttled, while memory pressure can result in termination.

Using Production for Stress Testing

Resource stress tests should run in isolated environments.

Looking Only at Average Usage

Applications often experience short CPU or memory spikes.

Ignoring Startup Behavior

Some applications require significantly more memory during startup than during steady-state execution.

Production Testing Strategy

A practical resource-tuning process is:

Deploy workload
      |
      v
Measure baseline
      |
      v
Observe CPU and memory
      |
      v
Test normal traffic
      |
      v
Test peak-like traffic
      |
      v
Check throttling and OOM events
      |
      v
Adjust requests and limits
      |
      v
Repeat measurement

Do not change resource values based on a single observation.

Applications can behave differently during startup, steady-state traffic, scheduled jobs, and failure recovery.

Best Practices

Measure Before Changing Values

Use real workload measurements.

Keep Requests Representative

Requests should provide Kubernetes with a reasonable estimate of the resources required by the application.

Give Memory Enough Headroom

Memory spikes can cause unexpected failures when limits are too close to normal usage.

Watch CPU Throttling

A service that constantly reaches its CPU limit may need a different limit or workload design.

Monitor Over Time

Resource usage should be evaluated across normal and peak operating periods.

Test After Runtime or Application Changes

A new application version can change CPU and memory requirements.

Advantages

Proper resource configuration provides:

More predictable scheduling
Better node utilization
Improved workload isolation
Easier capacity planning
Better visibility into application requirements
Reduced risk of uncontrolled resource consumption

Disadvantages and Trade-Offs

Poorly chosen values can create problems.

Configuration Problem	Possible Effect
Request too high	Scheduling inefficiency
Request too low	Resource contention
CPU limit too low	Throttling
Memory limit too low	OOM termination
Limit too high	Reduced isolation
No monitoring	Difficult troubleshooting

Resource management is therefore a balancing exercise rather than a matter of choosing the largest possible values.

Summary

Testing CPU and memory allocation in Kubernetes requires more than checking whether a pod is running.

Requests influence scheduling, while limits constrain runtime resource consumption. CPU and memory also behave differently under pressure, making it important to monitor them independently.

Use kubectl describe, kubectl top, controlled CPU and memory workloads, and production-like load tests to understand actual behavior.

For Kubernetes 1.37 workloads, the safest approach is to treat resource configuration as an engineering decision backed by measurements.

Set requests and limits based on observed workload behavior, test under realistic conditions, and continuously monitor CPU, memory, throttling, and OOM events after deployment.