What this calculates
Paste a Pod, or anything that embeds a pod template (Deployment, StatefulSet, DaemonSet, ReplicaSet, Job, CronJob), and get back the numbers Kubernetes itself derives from it: the total CPU and memory requested and limited per pod, the same totals multiplied by replicas for the whole workload, and the pod's QoS class — Guaranteed, Burstable, or BestEffort, the same three-way classification the scheduler and the kubelet actually use to decide eviction order under node pressure. BestEffort pods are evicted first when a node runs low on resources, Burstable next, and Guaranteed last.
The calculation accounts for a real, easy-to-miss Kubernetes default: if a container specifies a limit but no request for a resource, the request is automatically set equal to the limit at admission time — it's not left unset. This tool applies that same defaulting before computing totals and QoS, so a pod that only sets limits doesn't show up as requesting nothing, and correctly comes out Guaranteed when its limits alone already satisfy that class's requirements.
Every CPU limit also gets a note worth knowing even when nothing's wrong: a CPU limit can throttle a container even while the node has spare CPU sitting idle, since CPU throttling is enforced per-container on a fixed time window regardless of overall node load. Memory doesn't have an equivalent "throttle" — exceeding a memory limit gets the container OOM-killed instead — which is why it's common to set a CPU request without a CPU limit, while still setting both a memory request and limit.
What it doesn't do
This reads limits/requests directly from what you paste — it doesn't know about namespace-level LimitRange defaults that might inject a request or limit you didn't write explicitly, since those live in a separate object, not the manifest itself. A DaemonSet or CronJob total is shown per-pod (or per-scheduled-run), not multiplied by node count or run history, since neither is knowable from the manifest alone. For structural correctness rather than resource math, see Kubernetes YAML Validator.
FAQ
Why does a limit-only container come out Guaranteed?
Because Kubernetes copies the limit into the request automatically when no request is given — the pod you actually get scheduled has request equal to limit for that resource, which is exactly what Guaranteed requires. This tool reports the pod Kubernetes will actually run, not just what's literally typed in the YAML.
Should I always avoid setting a CPU limit?
It's a genuinely debated tradeoff, not a clear-cut rule — omitting it avoids artificial throttling but also removes the guardrail that stops one container from monopolizing a node's CPU. This tool surfaces the tradeoff as a note whenever a CPU limit is set, not as an error, since it's valid to want either behavior.