Kubernetes Resource Requests and Limits Checker
Check container and Pod-level CPU or memory declarations, quantity errors, missing fields, and request-limit conflicts.
Paste Pods or workload manifests. Multi-document YAML and Kubernetes List objects are supported.
Resource check settings
Findings
Output
Kubernetes resource findings will appear here.
A missing request is not always an absent runtime request
Requests influence scheduling. Limits control how much CPU or memory a workload may consume, but Kubernetes treats CPU and memory limits differently: CPU is throttled, while memory limits are enforced reactively and can lead to an OOM kill under pressure.
There is an important admission-time detail: when a resource has a limit but no request, Kubernetes can copy that limit into the request if no admission mechanism supplied another default. A namespace LimitRange can also inject defaults. This page therefore distinguishes “not written in this manifest” from “guaranteed to remain absent after admission.”
Pod-level resources change the review
Kubernetes supports Pod-level CPU and memory requests and limits behind the PodLevelResources feature, Beta since 1.34 and enabled by default in current Kubernetes releases. When a pasted Pod spec has spec.resources, the result shows that budget rather than pretending every container must carry the complete budget individually.
Limits are not a universal “must have” rule
Platform policy matters. Some teams require CPU and memory limits; others deliberately avoid CPU limits for latency-sensitive services. Missing limits are therefore reported as a policy decision unless another concrete conflict exists.
Quantity mistakes can be tiny on screen and huge in meaning
CPU 500m means half a CPU. Kubernetes does not accept CPU precision finer than 1m. Memory is measured in bytes and suffix case matters: 400Mi is hundreds of mebibytes, while 400m means four-tenths of a byte. The parser validates CPU and memory quantities before comparing request and limit values so those mistakes do not quietly become ordinary “missing field” findings.
Request greater than limit is a different class of finding
A container that explicitly requests more CPU or memory than its explicit limit is surfaced as a high-severity conflict. Pod-level budgets receive the same comparison. That is different from an omitted field, where admission defaults, Pod-level resources, or deliberate platform policy may still be involved.
Init containers need their own capacity reasoning
Init-container resources are listed so they cannot hide inside a workload review, but this page does not turn the table into a Pod scheduler calculation. Kubernetes uses special effective-resource rules for init containers, and restartable sidecar-style init containers add further accounting details. Use a dedicated calculator when you need Pod-level capacity totals.
What static YAML cannot answer
- Actual CPU usage, working-set memory, throttling, OOM history, or peak traffic.
- LimitRange defaults, ResourceQuota admission, mutating policies, or organization-specific policies unless those effects are already present in the pasted manifest.
- HPA or VPA recommendations, node allocatable capacity, scheduling constraints, or application SLOs.
- Effective Pod request calculations involving init-container sequencing, Pod overhead, or every current sidecar rule.
Kubernetes references behind these checks
The Kubernetes resource-management guide defines requests, limits, quantity units, limit-to-request fallback, and Pod-level resources. LimitRange documentation explains the namespace defaults that static workload YAML cannot see by itself.