Published: October 27, 2026 · 6 min read

Kubernetes Resource Limits — Quota, LimitRange and Pods

Kubernetes resource limits are set in three places. Nothing more.

Work down from the namespace to the container and it stays simple.

Here is the short version:

• ResourceQuota — the total for the whole namespace.
• LimitRange — the default and the max for each container.
• resources — what this container asks for.

1. ResourceQuota — the namespace total

This sits on the namespace and caps everything inside it together.

# resourcequota.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: hotel-quota
  namespace: hotel
spec:
  hard:
    requests.cpu: "2"             # all requests added up
    requests.memory: "4Gi"
    limits.cpu: "4"               # all limits added up
    limits.memory: "8Gi"
    pods: "10"                    # how many Pods may exist

kubectl apply -f resourcequota.yaml
# resourcequota/hotel-quota created

kubectl describe quota hotel-quota -n hotel
# Resource          Used     Hard
# --------          ----     ----
# limits.cpu        1500m    4
# limits.memory     1536Mi   8Gi
# pods              3        10
# requests.cpu      300m     2
# requests.memory   384Mi    4Gi

That Used and Hard table is the whole point. One command shows how much of the namespace budget is gone.

2. LimitRange — the per container defaults

This also sits on the namespace, but it works on each container.

# limit-range.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: hotel-limits
  namespace: hotel
spec:
  limits:
    - type: Container             # applies to EACH container
      defaultRequest:             # requests used when you write none
        cpu: "100m"
        memory: "128Mi"
      default:                    # limits used when you write none
        cpu: "500m"
        memory: "512Mi"
      max:                        # the highest one container may ask for
        cpu: "1"
        memory: "1Gi"

Three names, three jobs:

kubectl apply -f limit-range.yaml
# limitrange/hotel-limits created

kubectl describe limitrange hotel-limits -n hotel
# Type        Resource  Min  Max  Default Request  Default Limit
# ----        --------  ---  ---  ---------------  -------------
# Container   cpu       -    1    100m             500m
# Container   memory    -    1Gi  128Mi            512Mi

Everything in that table is per container. It is never a total for the namespace.

3. The Pod — where you write the real numbers

Now the bottom level. This is the only place you set numbers for your own application.

# deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hotel-app
  namespace: hotel
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hotel-app
  template:
    metadata:
      labels:
        app: hotel-app
    spec:
      containers:
        - name: hotel-app
          image: srinudev645/hotel-app:v1
          ports:
            - containerPort: 8080
          resources:              # <-- inside the CONTAINER
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

Follow the indentation: spec → template → spec → containers → resources.

kubectl apply -f deployment.yaml

kubectl describe pod hotel-app-7d4b9c6f85-2kq9x -n hotel
# Containers:
#   hotel-app:
#     Requests:
#       cpu:     100m
#       memory:  128Mi
#     Limits:
#       cpu:     500m
#       memory:  512Mi

Kubernetes Resource Limits in One Table

Write all three and nothing is left to chance. The namespace has a budget, every container has sensible values, and your application asks for exactly what it needs.

Quick Reference

# namespace total
kubectl get resourcequota -n hotel
kubectl describe quota hotel-quota -n hotel

# namespace defaults
kubectl get limitrange -n hotel
kubectl describe limitrange hotel-limits -n hotel

# what one Pod got
kubectl describe pod <pod-name> -n hotel
kubectl top pod -n hotel

What's Next

Three objects, three levels, and a cluster that stays predictable. The official ResourceQuota page (opens in a new tab) and the LimitRange page (opens in a new tab) go deeper when you need them.

← Back to Kubernetes Deployment

Frequently Asked Questions

Where are Kubernetes resource limits set?

In three places. A ResourceQuota sits on the namespace and caps the total for everything inside it. A LimitRange also sits on the namespace and gives each container its default and maximum values. The resources block sits on the container inside a Pod. That is the only place you write numbers for your own application.

What is a ResourceQuota in Kubernetes?

A ResourceQuota is a cap on a whole namespace. You set how much CPU and memory everything inside it may ask for in total. You also set how many Pods may exist. Kubernetes adds up every container in the namespace and compares it against your numbers. It is how you stop one team taking the whole cluster.

What is a LimitRange in Kubernetes?

A LimitRange is a rule on a namespace that works on each container. It has three useful fields. defaultRequest becomes the requests when a container writes none. default becomes the limits when a container writes none. max is the highest a single container may be configured with.

What is the difference between requests and limits?

A request is what is reserved for the container. The scheduler reads it to choose a node with enough room, and the node then holds that amount aside. A limit is the most the container may ever use. Between the two it can borrow spare capacity when the node is quiet.

Do resource limits go on the Pod or the container?

On the container. The resources block sits under spec.containers, right next to the image and the ports. A Pod has no resources field of its own, and neither does a Deployment. What people call the Pod request is simply the requests of all its containers added together.

What is the difference between ResourceQuota and LimitRange?

A ResourceQuota caps the total for the whole namespace. A LimitRange works on each container. It fills in values that were left out, and caps what one container may ask for. They do not replace each other. Use a ResourceQuota for the namespace budget and a LimitRange so no container is left with nothing.