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.
\nThe Pod Quality of Service Classes documentation is the primary reference.
\nUnder 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.
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.
\nDSE recommends reviewing a per-container resource matrix and the actual assigned QoS class before accepting a workload change.
\nList 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.
\nHave 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.
\nReview 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.
\nRetain 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.
\nProposed 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.
\nPredict 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe Pod Quality of Service Classes documentation is the primary reference.\nUnder 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich containers belong to the effective Pod definition?\nDoes each required CPU and memory pair satisfy the intended class?\nWhich defaults or admission changes appear on the created object?\nIs a planned resource change intended to preserve the existing class?\n\nDSE recommendation: reconcile the whole Pod resource matrix\nDSE recommends reviewing a per-container resource matrix and the actual assigned QoS class before accepting a workload change.\nList 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.\nHave 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.\nReview 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.\nRetain 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.\nVerification and evidence\nProposed 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.\nPredict 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.\nOfficial references\n\nPod Quality of Service Classes — Kubernetes.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [Pod Quality of Service Classes](https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/) documentation is the primary reference.\n\nUnder 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which containers belong to the effective Pod definition?\n\n- Does each required CPU and memory pair satisfy the intended class?\n\n- Which defaults or admission changes appear on the created object?\n\n- Is a planned resource change intended to preserve the existing class?\n\n## DSE recommendation: reconcile the whole Pod resource matrix\n\nDSE recommends reviewing a per-container resource matrix and the actual assigned QoS class before accepting a workload change.\n\nList 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.\n\nHave 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.\n\nReview 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.\n\nRetain 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.\n\n## Verification and evidence\n\nProposed 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.\n\nPredict 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.\n\n## Official references\n\n- [Pod Quality of Service Classes](https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/) — Kubernetes.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/check-every-container-before-accepting-a-kubernetes-qos-class/", "url": "https://update.dsesecurity.com/updates/check-every-container-before-accepting-a-kubernetes-qos-class/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/check-every-container-before-accepting-a-kubernetes-qos-class/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Check every container before accepting a Kubernetes QoS class", "item": "https://update.dsesecurity.com/updates/check-every-container-before-accepting-a-kubernetes-qos-class/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/check-every-container-before-accepting-a-kubernetes-qos-class/#article", "identifier": "https://update.dsesecurity.com/updates/check-every-container-before-accepting-a-kubernetes-qos-class/", "url": "https://update.dsesecurity.com/updates/check-every-container-before-accepting-a-kubernetes-qos-class/", "headline": "Check every container before accepting a Kubernetes QoS class", "description": "Review ordinary container-level CPU and memory request-limit pairs across the whole Pod.", "abstract": "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.", "articleBody": "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.\nSource fact: documented behavior\nThe Pod Quality of Service Classes documentation is the primary reference.\nUnder 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich containers belong to the effective Pod definition?\nDoes each required CPU and memory pair satisfy the intended class?\nWhich defaults or admission changes appear on the created object?\nIs a planned resource change intended to preserve the existing class?\n\nDSE recommendation: reconcile the whole Pod resource matrix\nDSE recommends reviewing a per-container resource matrix and the actual assigned QoS class before accepting a workload change.\nList 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.\nHave 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.\nReview 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.\nRetain 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.\nVerification and evidence\nProposed 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.\nPredict 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.\nOfficial references\n\nPod Quality of Service Classes — Kubernetes.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T20:32:56+00:00", "dateModified": "2026-10-29T20:33:35+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/check-every-container-before-accepting-a-kubernetes-qos-class/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/check-every-container-before-accepting-a-kubernetes-qos-class/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Check every container before accepting a Kubernetes QoS class" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 598, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Kubernetes — Pod Quality of Service Classes", "url": "https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/" } } ] } }