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.
Fixes must specify requests.cpu, requests.memory
# Check ResourceQuota
kubectl describe resourcequota -n <namespace>
# Check LimitRange
kubectl describe limitrange -n <namespace># Check ResourceQuotakubectl describe resourcequota -n <namespace># Check LimitRangekubectl describe limitrange -n <namespace>must specify requests.cpu, requests.memory
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