Kubernetes assigns a Pod’s Quality of Service (QoS) class from its CPU and memory requests and limits; no single number decides the class. To expand persistent storage, you must also distinguish three stages: increasing the PVC request, expanding the backing volume, and—when needed—growing the filesystem so the mounted Pod can use the extra space.
How Kubernetes decides a Pod’s QoS class
Kubernetes assigns every Pod one of three QoS classes: Guaranteed, Burstable, or BestEffort. The class is based on CPU and memory resource requests and limits across the Pod’s containers. It influences how Kubernetes orders Pods for eviction when a node is under resource pressure; it is not a promise that a Pod cannot be terminated. See the Kubernetes QoS documentation.
| Class | How to identify it |
|---|---|
| Guaranteed | Every applicable container has positive CPU and memory requests and limits, and each request equals its corresponding limit. |
| Burstable | At least one CPU or memory request or limit is set, but the Pod does not meet the Guaranteed criteria. |
| BestEffort | No CPU or memory requests or limits are set for the Pod’s containers. |
For example, a container with a CPU request but no matching CPU limit does not qualify for Guaranteed. If any CPU or memory setting exists, that Pod is generally Burstable unless all Guaranteed requirements are met.
Check the effective class
Inspect the Pod rather than inferring the class from a single container’s manifest. The assigned class is shown in the Pod’s status.qosClass. Kubernetes documents the per-container rules and a configuration example in Configure Quality of Service for Pods.
#1 Best Overall
Current Kubernetes QoS documentation also describes Pod-level CPU and memory resources as beta since Kubernetes v1.34 and enabled by default. Because feature availability depends on the cluster version and configuration, use the rules documented for the version actually running in your cluster.
What QoS does—and does not—change
A Pod’s QoS class is established when the Pod is created and remains fixed for its lifetime. Changing CPU or memory resources in place does not change that class. QoS is relevant to eviction handling under node pressure, but a container that exceeds its limit may be killed and restarted independently of its QoS class. The in-place resource resize documentation covers version-specific constraints; it also distinguishes CPU and memory resizing from storage resizing.
Disk-backed emptyDir volumes and persistent volumes cannot be resized through a Pod’s /resize subresource. A PVC expansion is a separate storage workflow.
Expanding a Kubernetes persistent volume takes three steps
Editing a PVC raises the requested capacity; it is not, by itself, proof that the backing storage and mounted filesystem are ready to use that capacity. Expansion depends on support from the StorageClass and the storage implementation.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →1. Request more capacity on the PVC
First confirm that the PVC’s StorageClass has allowVolumeExpansion: true. The volume type and its provisioner or CSI driver must also support expansion. Then edit the PVC’s requested storage upward. PVC expansion is stable in Kubernetes v1.24 and later, but a PVC cannot be shrunk through this feature. See Storage Classes and Persistent Volumes.
Kubernetes resizes the existing backing volume rather than creating a replacement PV for the larger request. Do not edit the PV’s capacity directly as a substitute for updating the PVC: if the PV and PVC appear to match, the control plane may conclude that no resize is needed.
2. Wait for the backing volume to expand
The provisioner or CSI driver performs the infrastructure-side expansion. Its capabilities and completion time are specific to the driver and storage provider. Kubernetes v1.24 and later enables CSI volume expansion by default, but the particular CSI driver still has to support it.
If a request exceeds the capacity available from the storage backend, the resize can fail and continue to be retried until an operator takes action. Expansion is grow-only; plan the requested size carefully because Kubernetes does not offer a matching shrink operation.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall3. Confirm filesystem growth when the volume uses a filesystem
A larger block volume does not always mean the mounted filesystem already exposes the additional capacity. Kubernetes documents filesystem expansion for XFS, Ext3, and Ext4. For these filesystems, expansion occurs when a Pod uses the claim in ReadWrite mode—at startup, or online where the filesystem supports it.
Check both the PVC’s resize state and the capacity visible inside the consuming Pod before treating the extra space as available. Kubernetes documents that an in-use PVC can become available to its Pod after filesystem expansion completes without deleting and recreating the Pod; actual behavior still depends on the filesystem and storage implementation.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What to verify before and after a resize
- StorageClass: Confirm
allowVolumeExpansion: true. - Storage implementation: Check that the volume type and provisioner or CSI driver support expansion.
- Filesystem and use: Identify the filesystem, whether the claim is in use, and its access mode; these affect filesystem expansion behavior.
- Observed capacity: Confirm that the PVC and the mounted filesystem both reflect the intended size before relying on the additional space.
- Provider constraints: Check the provider or driver’s capacity limits, timing, interruption expectations, and costs. Kubernetes-wide documentation cannot establish these for an unspecified storage system.
Do not assume that expansion is interruption-free for every provider or driver. Although Kubernetes supports completing some in-use PVC expansions without recreating the Pod, the exact behavior depends on the underlying implementation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
