Check CSI attachment slots before adding storage capacity

Bottom line: Check the attachment constraint as well as the storage request when a Pod waits for a volume. Keep the intended node, driver and attachment population in the investigation so extra storage capacity is not the automatic response to every pending workload.

Source fact: documented behavior

The Node-specific Volume Limits documentation is the primary reference.

The guide explains that exceeding a provider’s per-node volume limit can leave scheduled Pods waiting for attachment. When a CSI driver advertises a node maximum through NodeGetInfo, the Kubernetes scheduler honors that limit. For in-tree volume plugins migrated to CSI, the maximum is the one reported by the CSI driver.

What the source does not establish

This article reviews attachment-slot evidence, not a universal volume count or a storage-performance guarantee. It excludes the guide’s separate mutable-limit refresh and missing-driver placement features. Confirm the installed driver and node type instead of copying a cloud-provider example count into the operating procedure.

Applicability questions

• Which node and CSI driver are associated with the pending workload?
• What maximum does the driver report for that node?
• Which existing attachments and requested volumes are relevant?
• Does the evidence identify a slot constraint, capacity issue or another failure?

DSE recommendation: separate attachment and capacity findings

DSE recommends an attachment worksheet for the specific incident. Record the Pod, requested volumes, intended or observed node, driver identity and available status or event evidence. Keep the requested storage amount in its own field rather than using it as a substitute for the attachment population.

Ask the storage and cluster owners to reconcile the reported maximum with the actual node and driver configuration. Review migrated-plugin cases explicitly. Mark an unavailable or unexplained report as unresolved rather than selecting a number from the guide’s illustrative cloud table.

Review existing attachments through the product’s supported administrative workflow. Identify which are active, expected or under separate investigation before proposing removal. Do not detach a volume holding valuable data merely to test whether a new Pod will start. Keep application-data ownership involved in any cleanup decision.

Choose the corrective path from the demonstrated constraint. A placement change, attachment cleanup and storage expansion need different approvals and evidence. Preserve the original pending-state observations and change one reviewed factor at a time so the team can explain what resolved the problem. Keep mutable-limit configuration outside this narrower investigation unless separately reviewed.

Verification and evidence

Proposed verification, not performed: use a dedicated test node and disposable volumes under the installed driver’s documented procedure. Record the reported maximum and the agreed bounded attachment population before exercising the chosen pending-workload case. Avoid exhausting a shared production node for demonstration.

Retain the Pod’s scheduling and attachment observations, driver report, node identity and actual result after the approved correction. Inspect the harmless test data separately from attachment status. Reconcile remaining attachments during cleanup, and report any untested driver or node variation rather than claiming the result applies to every storage path.

Official references

• Node-specific Volume Limits — Kubernetes.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.