This admission error occurs when ResourceQuota or LimitRange requires containers to specify resource requests. Fix it by adding explicit requests.cpu and requests.memory to your container spec.
The "must specify requests.cpu, requests.memory" error occurs when a namespace has policies requiring all containers to declare resource requests, but your Pod spec is missing these fields. Resource requests tell Kubernetes the minimum resources a container needs. The scheduler uses requests to find suitable nodes—a pod is only placed on a node if it has enough unrequested capacity. Without requests, Kubernetes can't properly schedule pods or track namespace resource consumption. When ResourceQuota tracks requests.cpu/requests.memory, all pods must specify these values so the quota controller can accurately measure usage against limits.
View ResourceQuota and LimitRange requirements:
# Check ResourceQuota
kubectl describe resourcequota -n <namespace>
# Check LimitRange
kubectl describe limitrange -n <namespace>If ResourceQuota shows requests.cpu or requests.memory in spec.hard, pods must specify these.
Add requests (and limits) to your container:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "250m" # Required - guaranteed minimum
memory: "256Mi" # Required - guaranteed minimum
limits:
cpu: "500m"
memory: "512Mi"Apply:
kubectl apply -f pod.yaml -n <namespace>Add resources to all containers in the template:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
template:
spec:
containers:
- name: app
image: my-image
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "512Mi"Apply:
kubectl apply -f deployment.yaml
kubectl get pods -n <namespace>Check current pod resource consumption:
# View actual usage of running pods
kubectl top pods -n <namespace>
# Get detailed resource metrics
kubectl top pods -n <namespace> --containersSet requests slightly above typical usage:
resources:
requests:
cpu: "100m" # If typical usage is 80m
memory: "128Mi" # If typical usage is 100Mi
limits:
cpu: "500m" # Allow bursting to 5x
memory: "256Mi" # Allow some headroomAdmin can set defaults so pods without requests still work:
apiVersion: v1
kind: LimitRange
metadata:
name: default-resources
namespace: <namespace>
spec:
limits:
- type: Container
defaultRequest:
cpu: "100m"
memory: "64Mi"
default:
cpu: "500m"
memory: "256Mi"Apply:
kubectl apply -f limitrange.yamlNow pods without explicit requests receive defaultRequest values.
Confirm pods are created and scheduled:
# Watch pod creation
kubectl get pods -n <namespace> -w
# Verify resource allocation
kubectl describe pod <pod-name> -n <namespace> | grep -A3 "Requests"
# Check QoS class
kubectl get pod <pod-name> -o jsonpath='{.status.qosClass}'If pod is Pending, check node capacity:
kubectl describe nodes | grep -A5 "Allocated resources"Requests vs Limits:
- Requests: Minimum guaranteed; used for scheduling decisions
- Limits: Maximum allowed; enforced at runtime
- Scheduler only considers requests, not limits
Scheduling Impact:
- Pod placed on node only if: node available capacity >= pod total requests
- Over-requesting prevents scheduling
- Under-requesting causes contention at runtime
CPU Units:
- 1 = 1 full core
- 500m = 0.5 cores (half a CPU)
- 100m = 0.1 cores
Memory Units:
- Mi = mebibytes (1024²)
- Gi = gibibytes (1024³)
- M = megabytes (1000²)
QoS Classes:
- Guaranteed: requests = limits → least likely eviction
- Burstable: requests < limits → medium priority
- BestEffort: no resources → evicted first
Best Practices:
1. Set requests based on profiled typical usage
2. Set limits 2-4x requests for burstable workloads
3. Use requests = limits for critical workloads (Guaranteed QoS)
4. Monitor actual usage with kubectl top pods and adjust
No subnets found for EKS cluster
How to fix "eks subnet not found" in Kubernetes
unable to compute replica count
How to fix "unable to compute replica count" in Kubernetes HPA
error: context not found
How to fix "error: context not found" in Kubernetes
default backend - 404
How to fix "default backend - 404" in Kubernetes Ingress
serviceaccount cannot list resource
How to fix "serviceaccount cannot list resource" in Kubernetes