Context
A Deployment can exist even when its ReplicaSet cannot create a Pod. Namespace policy is checked when the Pod is admitted, so the failure may appear in controller events rather than in a Pending Pod. ResourceQuota limits aggregate namespace allocation or object counts. LimitRange constrains individual resource declarations and can supply defaults.
You need the namespace, workload name, intended resource requests, and permission to read policy objects and controller events. This investigation concerns declared allocation rather than current CPU or memory utilization. A quiet namespace can still have its request quota fully allocated.
1. Locate the admission error
kubectl -n shop describe deployment catalog
kubectl -n shop get replicasets -l app=catalog
kubectl -n shop describe replicaset catalog-new
The ReplicaSet name is illustrative; use the one owned by your Deployment. Read the exact forbidden message and affected resource. If a Pod already exists and is Pending because no node fits, that is a scheduling question rather than the same admission failure. Keep the two stages separate in the incident record.
2. Read both policy objects
kubectl -n shop get resourcequota -o yaml
kubectl -n shop get limitrange -o yaml
kubectl -n shop get pods -o yaml
Compare quota hard limits with reported used values. Then inspect LimitRange minimums, maximums, default limits, default requests, and limit-to-request ratios. Missing resources in a template may be filled during admission. Review all regular containers and relevant initialization resources rather than assuming the application's main container is the entire Pod allocation.
Inspect an already admitted representative Pod to see its effective resource fields. The source manifest alone may omit the defaults that explain aggregate usage. A new LimitRange also does not automatically rewrite every existing Pod, so old and new replicas can have different effective declarations.
3. Calculate the requested change
For an explicitly illustrative example, a namespace has request quota for its steady-state replicas but no room for a rolling update's additional Pod. Current CPU usage is low, yet the new Pod is rejected because quota accounts for declared requests. Separately, a LimitRange default can make an omitted request consume more allocation than the release author expected.
Write down the existing declared total, the new Pod's effective request, and temporary rollout overlap. Use those observed inputs to review headroom. Do not substitute a dashboard's momentary usage figure for the API's allocation accounting.
Classify the policy failure
| Rejection or evidence | Policy boundary | Next comparison |
|---|---|---|
| exceeded quota for requests.cpu | Namespace aggregate | Used allocation plus incoming request |
| must specify a resource request | Required declaration | Template fields and defaulting |
| maximum memory limit violated | Individual allocation | Container value against LimitRange |
| limit-to-request ratio rejected | Per-object ratio | Effective request and limit together |
Correct an accidental resource declaration in the workload. If legitimate capacity exceeds policy, request a reviewed quota change with the namespace owner. Lowering requests solely to bypass quota can distort scheduling expectations; changing rollout surge can change availability or duration. Choose a correction that preserves the application's operating requirements.
Verify admission and preserve a capacity SOP
After the approved change, confirm the ReplicaSet creates the expected Pods and inspect their admitted resources. Verify successful rollout and a harmless application transaction. Recheck quota used values once old replicas terminate so temporary overlap is understood.
Maintain an explicit resource budget containing steady-state allocation, release headroom, defaulting rules, and policy owners. Monitor admission rejection events as well as quota utilization. Add a policy check to release review when container counts, initialization behavior, requests, or rollout strategy change.
Explore Clouvenix containers kubernetes for implementation and operational handover.