Cloud Native 8 min read

Setting Default Resource Requests and Limits for Pods in a Kubernetes Namespace

This tutorial explains how to configure default CPU and memory requests and limits for containers in a Kubernetes namespace using LimitRange objects, demonstrates the effect with several pod examples, and shows how to clean up the resources afterward.

360 Tech Engineering
360 Tech Engineering
360 Tech Engineering
Setting Default Resource Requests and Limits for Pods in a Kubernetes Namespace

Kubernetes allows you to specify CPU and RAM requests and limits for individual pods, which is useful for managing per‑pod resource consumption. This article introduces three strategies for efficient cluster‑wide resource management, focusing on the first: setting default resource requests and limits for containers in a namespace.

Define default resource requests and limits in a namespace

First, create a new namespace where the defaults will apply:

kubectl create namespace default-resources-config
namespace "default-resources-config" created

Then define a LimitRange object that specifies the default values:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-requests-and-limits
spec:
  limits:
  - default:
      memory: 512Mi
      cpu: 0.8
    defaultRequest:
      memory: 256Mi
      cpu: 0.4
    type: Container

Save this as limit-range-1.yaml and apply it to the namespace:

kubectl create -f limit-range-1.yaml --namespace=default-resources-config
limitrange "default-requests-and-limits" created

Now any pod created in default-resources-config that does not specify its own requests or limits will receive the defaults defined above. Example pod definition:

apiVersion: v1
kind: Pod
metadata:
  name: default-resources-demo
spec:
  containers:
  - name: default-resources-cont
    image: httpd:2.4

Create the pod:

kubectl create -f default-resources-demo-pod.yaml --namespace default-resources-config
pod "default-resources-demo" created

Inspect the pod to see the injected resources:

kubectl get pod default-resources-demo --output=yaml --namespace=default-resources-config
containers:
  - image: httpd:2.4
    name: default-resources-cont
    resources:
      limits:
        cpu: 800m
        memory: 512Mi
      requests:
        cpu: 400m
        memory: 256Mi

If you specify only limits, Kubernetes will automatically set matching requests:

apiVersion: v1
kind: Pod
metadata:
  name: default-resources-demo-2
spec:
  containers:
  - name: default-resources-cont
    image: httpd:2.4
    resources:
      limits:
        memory: "1Gi"
        cpu: 1
kubectl create -f default-resources-demo-2.yaml --namespace default-resources-config
pod "default-resources-demo-2" created

Checking the pod shows both limits and requests set to the same values.

When you provide only requests, the default limits are applied:

apiVersion: v1
kind: Pod
metadata:
  name: default-resources-demo-3
spec:
  containers:
  - name: default-resources-cont
    image: httpd:2.4
    resources:
      requests:
        memory: "0.4Gi"
        cpu: 0.6
kubectl create -f default-resources-demo-3.yaml --namespace default-resources-config
pod "default-resources-demo-3" created

Inspecting this pod yields the default limits (800m CPU, 512Mi memory) combined with the specified requests.

Note: If a container’s request exceeds the default limit, the pod creation will fail.

Cleanup

After the examples, delete the namespace to clean up:

kubectl delete namespace default-resources-config
namespace "default-resources-config" deleted

The article concludes by stating that the next parts of the series will cover defining minimum and maximum resource constraints and setting resource quotas for all containers in a namespace.

Kubernetesresource managementDevOpsyamlnamespacedefault-resourceslimitrange
360 Tech Engineering
Written by

360 Tech Engineering

Official tech channel of 360, building the most professional technology aggregation platform for the brand.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.