# Include RuntimeClass overhead in a Kubernetes Pod resource review > Pod overhead is set at admission from RuntimeClass and counted beyond container requests. Inspect the admitted Pod and the combined budget before explaining placement or quota results. - Canonical URL: https://update.dsesecurity.com/updates/include-runtimeclass-overhead-in-a-kubernetes-pod-resource-review/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T19:49:23+00:00 - Modified: 2026-10-29T19:50:09+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Pod overhead is set at admission from RuntimeClass and counted beyond container requests. Inspect the admitted Pod and the combined budget before explaining placement or quota results. ## Potentially affected Review scope: documented RuntimeClass Pod overhead and request accounting; example runtime sizes and direct cgroup paths are not universal deployment values. ## DSE recommendation Reconcile the selected RuntimeClass, admitted overhead and container requests before accepting the Pod's scheduling and quota budget. ## Article Bottom line: Review the complete admitted Pod budget before explaining a scheduling result from container requests alone. Keep the RuntimeClass requirement and its overhead visible beside the workload’s own resource needs. ## Source fact: documented behavior The [Pod Overhead](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-overhead/) documentation is the primary reference. Kubernetes sets Pod overhead at admission from the overhead associated with the Pod’s RuntimeClass. Scheduling considers overhead in addition to container requests, and the documented quota calculation also counts that overhead. The RuntimeClass admission controller adds overhead to the Pod specification; the guide says a Pod with that field already defined is rejected. ## What the source does not establish This article reviews the Pod resource-accounting decision, not a universal runtime cost or a guarantee of workload performance. The source’s example numbers and cgroup layout are illustrative. Obtain the actual runtime requirement and installed-cluster evidence before selecting a budget. ## Applicability questions - Which RuntimeClass does the workload actually select? - What overhead does that approved RuntimeClass define? - What container requests and admitted Pod overhead are observed? - Which quota or node-placement requirement must the combined budget satisfy? ## DSE recommendation: reconcile the admitted budget DSE recommends a resource worksheet with separate rows for container requests and RuntimeClass overhead. Have the runtime owner supply the actual approved definition and the application owner supply the workload requirement. Keep an unknown overhead unresolved instead of adopting the tutorial’s illustrative runtime cost. Inspect the managed workload definition and selected RuntimeClass before changing requests. Record the intended association and compare it with the admitted Pod. Keep direct manual assignment of the overhead field outside the ordinary workload procedure; follow the documented admission path and investigate an unexpected rejection. Reconcile the combined requirement with the relevant quota and node observations. Preserve the actual Pod identity and observation time so the review does not combine one manifest revision with another admitted object. Do not reduce a container request merely to offset an unexplained infrastructure charge. Keep resource accounting separate from application acceptance. Ask the workload owner to define a bounded functional observation after scheduling, and ask the runtime owner to explain any change in the overhead definition. Review an intentional RuntimeClass change as a new resource decision rather than assuming it preserves the old budget. ## Verification and evidence Proposed verification, not performed: use a disposable workload and an already approved test RuntimeClass. Write the expected container-request total and the RuntimeClass overhead as separate inputs, then inspect the actual admitted Pod and the corresponding quota or node accounting through supported tools. Repeat with one deliberately changed harmless container request while keeping the RuntimeClass fixed. If a second RuntimeClass is available and separately approved, treat it as another case with its own expected overhead. Retain the definitions, Pod identity, admitted values and accounting observations. Record missing evidence or an unexplained result without presenting the source’s sample arithmetic as a measurement of the deployment. ## Official references - [Pod Overhead](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-overhead/) — Kubernetes. Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — Pod Overhead - Authority: kubernetes.io - URL: https://kubernetes.io/docs/concepts/scheduling-eviction/pod-overhead/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Include RuntimeClass overhead in a Kubernetes Pod resource review,” DSE Security, https://update.dsesecurity.com/updates/include-runtimeclass-overhead-in-a-kubernetes-pod-resource-review/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.