# Check every container before accepting a Kubernetes QoS class > Review ordinary container-level CPU and memory request-limit pairs across the whole Pod. Keep its assigned QoS class separate from an availability or performance guarantee. - Canonical URL: https://update.dsesecurity.com/updates/check-every-container-before-accepting-a-kubernetes-qos-class/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T20:32:56+00:00 - Modified: 2026-10-29T20:33:35+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 Review ordinary container-level CPU and memory request-limit pairs across the whole Pod. Keep its assigned QoS class separate from an availability or performance guarantee. ## Potentially affected Kubernetes Pods using container-level CPU and memory resource declarations; the separate beta Pod-level resource and MemoryQoS mechanisms are outside this article. ## DSE recommendation DSE recommends reviewing a per-container resource matrix and the actual assigned QoS class before accepting a workload change. ## Article Bottom line: Review the complete Pod when a workload requires a particular resource class. A correctly configured main application container is insufficient evidence for a multi-container definition; reconcile the submitted requirements with the object actually created. ## Source fact: documented behavior The [Pod Quality of Service Classes](https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/) documentation is the primary reference. Under the documented container-level Guaranteed criteria, each resource-bearing container needs positive CPU and memory requests and limits, with each request equal to its corresponding limit. Without Pod-level CPU or memory declarations, BestEffort requires that no container declare CPU or memory requests or limits; requests for other resources do not necessarily change that class. The assigned QoS class remains fixed for the Pod lifetime, and an in-place resize that would change it is rejected by admission. The page labels its separate Pod-level resource criteria and MemoryQoS mechanisms beta; those branches are outside this container-level review. ## What the source does not establish This review covers ordinary application and startup-container resource worksheets. Handle ephemeral debugging containers through their separate supported procedure, and leave Pod-level resources and MemoryQoS tuning to a version-specific assessment. Do not translate a class name into a promise of uninterrupted service, a measured latency target or an appropriate resource size. Require the workload owner to justify the requested amounts independently. ## Applicability questions - Which containers belong to the effective Pod definition? - Does each required CPU and memory pair satisfy the intended class? - Which defaults or admission changes appear on the created object? - Is a planned resource change intended to preserve the existing class? ## DSE recommendation: reconcile the whole Pod resource matrix DSE recommends reviewing a per-container resource matrix and the actual assigned QoS class before accepting a workload change. List the effective containers beside their CPU request, CPU limit, memory request and memory limit. Include relevant startup and supporting containers in the review rather than copying the main process row across the worksheet. Have the cluster administrator resolve which supported resource mechanism applies before using this container-level procedure. Have the application owner state the intended class and the separate reason for each resource amount. Inspect the submitted manifest and the created object through approved tools. Record any defaulted or changed values instead of claiming that the file alone describes the accepted runtime object. Investigate an unexpected class against every row before increasing several limits at once. Review a proposed resize against the existing class before submitting it. If the intended change needs a different class, obtain the appropriate supported workload-replacement plan and continuity assessment. Keep that lifecycle decision visible; repeatedly retrying a rejected resize is not a substitute for deciding how the workload will be recreated. Retain the prior definition and the accepted replacement or resize plan with the application owner. Require separate performance and recovery observations before calling the resulting resource allocation suitable for production. ## Verification and evidence Proposed verification, not performed: prepare disposable ordinary container-level Pods with one fully matched set of CPU and memory pairs, another with a supporting container that breaks the intended criteria, and a third with no CPU or memory declarations. Use harmless workloads and conservative approved resource amounts. Predict the class from the complete matrix, create each approved fixture and read its actual object and assigned class. Reconcile every difference before testing a class-changing resize in the disposable environment. Preserve the submitted definition, effective values, admission outcome and actual class. Keep these observations separate from application performance, failover and node-pressure testing; none has been performed for this article. ## Official references - [Pod Quality of Service Classes](https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/) — Kubernetes. Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Kubernetes — Pod Quality of Service Classes - Authority: kubernetes.io - URL: https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check every container before accepting a Kubernetes QoS class,” DSE Security, https://update.dsesecurity.com/updates/check-every-container-before-accepting-a-kubernetes-qos-class/ 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.