Local Persistent Volumes Bind GPU Placement to a Node

Follow the claim to the storage on its node

A persistent-local-storage offer contains two useful promises to distinguish: retaining a storage resource beyond one worker and making that worker's required data accessible wherever a replacement can run. The word persistent does not make those promises equivalent.

Kubernetes separates the backing storage from the objects describing its use. For the built-in local volume, the backing is a mounted local disk, partition or directory. The PersistentVolume, or PV, is the cluster storage resource describing that implementation. A PersistentVolumeClaim, or PVC, requests storage; a consuming Pod refers to the claim. The PV has a lifecycle independent of any individual Pod.

Now follow that relationship to placement. A local PV requires node affinity, and Kubernetes uses it to constrain the consuming Pod's node. Bound describes the PV's association with a claim. It supplies no observation that the storage is currently readable.

This article uses the official archived Kubernetes v1.34 static documentation, checked October 20, 2026, for the built-in local implementation. Other storage drivers and vendor architectures require their own evidence.

References: [PV1][PV2]

Identify whether the worker restarts inside its Pod or is replaced

The container process is another layer. Kubernetes may restart a failed container inside its existing Pod. That leaves the Pod's UID and assigned node unchanged. It creates no new opportunity to choose node B.

A replacement Pod has a different UID, even if it reuses the old Pod's name. A given Pod UID is scheduled only once; replacement is a new placement decision rather than the original Pod travelling between nodes.

For a replacement that uses the same still-bound claim, the new UID does not remove the existing volume constraint. Conversely, a container restart on the original node establishes no evidence about replacement placement elsewhere. When a proposal says the worker restarts automatically, establish which of these events it means before interpreting its storage promise.

References: [PV2][PV3]

PV-110: spare GPUs and eligible storage can occupy different nodes

Consider original hypothetical PV-110. One replacement Pod requires two compatible GPUs and dataset D. Its claim is already bound to exact local PV V, whose node affinity permits only node A. Stipulate that D is present in V's backing storage on A and that no accessible copy on B has been established.

At this replacement scheduling decision, A has zero available compatible GPUs and B has four. The example excludes other placement constraints solely to isolate the compute-and-volume comparison. These are stipulated inputs, not observations from a deployment.

The GPU-count-feasible node set is {B}. The volume-affinity-eligible node set is {A}. Their intersection is empty: no node satisfies both requirements. Four available GPUs across the two-node cluster and a Bound claim therefore do not supply one placement for this Pod.

The mismatch has a specific consequence for an expansion offer. Adding more GPUs only on B would leave the intersection empty under the unchanged volume premise. Adding another empty disk on B would also leave the requirement for D through V unanswered. Neither addition resolves the missing relationship between the required compute and the required data.

As a separate comparison, suppose A instead has two available compatible GPUs and its local storage is accessible. A then passes this limited two-constraint screen. That change establishes a candidate, not an observed scheduling, successful mount or useful application result. The distinction is useful: an empty intersection rules the placement out, while a candidate leaves later questions to answer.

References: [PV1][PV2]

The same directory name on B does not establish access to D

Keep PV-110's required workload and dataset unchanged. Suppose an offer shows a same-capacity disk on B and a directory whose path has the same spelling as the local path on A. Those descriptions do not establish that B contains D. A path is interpreted on its own node; repeating its text supplies no relationship between the two stores' contents.

The same applies to the path presented inside a container. A familiar mount location can help the application find its files once the correct storage is accessible, but the string itself neither identifies a data copy nor creates one. Keeping the claim and path names unchanged cannot bridge PV-110's empty intersection.

If A becomes unhealthy, the documented local-volume dependency can make the storage inaccessible and prevent the consuming Pod from running. That loss of accessibility alone does not establish that D's bytes were destroyed. Kubernetes separately warns of potential loss depending on the underlying disk's durability. A claim of a usable copy elsewhere needs evidence connecting that copy to D; an access failure is not such evidence.

References: [PV1]

Delayed binding improves the initial choice of storage

Before a claim is bound, the timing of storage selection matters. Binding topology-constrained storage without considering the consumer can leave a Pod without a compatible node. Delayed binding allows the selection to take the Pod's requirements into account.

The v1.34 Storage Classes documentation explicitly includes local volumes in support for delayed binding to pre-created PVs. That is different from dynamic provisioning, which this local implementation does not support.

Imagine an initial choice between two pre-created local PVs that match the claim's storage requirements. Considering the intended consumer's node requirements can avoid selecting one on an incompatible node. For an application needing an existing dataset, however, a matching capacity alone still does not establish that the selected volume contains the required data.

PV-110 is already past that initial choice: its claim is bound to V, and D is on A by premise. A statement that the platform supports delayed binding does not explain how this replacement could use D on B. Selection timing supplies neither remote replication nor migration of an already-bound payload.

References: [PV4]

Compare retention, replacement placement and application continuation

Read competing offers against the same PV-110 workload and D. An offer showing that V and its claim remain present supports a retained-resource statement. It has not answered the replacement Pod's empty compute-and-volume intersection.

An offer showing a two-GPU worker on B against a different empty volume changes the storage requirement. It demonstrates neither access to D nor continuation of the requested work. More storage capacity is an answer to a capacity question; it cannot silently substitute for the required contents.

An offer showing a replacement placed on A with access to D answers more of the original question. It still leaves the application's continuation requirement to establish. For example, the buyer may require resuming from a particular retained application state rather than merely reopening dataset files. Whether that state exists and is usable is the separate checkpoint-content question covered by the related guide.

Request an explanation from the appointed platform and storage owners that connects the required data, the claim-to-volume association, the local backing node and the replacement Pod's eligible nodes at the stated time. The explanation should distinguish a modeled candidate from an observed result. If useful continuation is promised, its evidence needs to address the application's required state and work, beyond the existence of a new worker.

These comparisons support different purchasing decisions. A retained local resource may meet a retention requirement. A promise of replacement on another node needs a supported data-access relationship as well as compute fit. A promise that the application continues needs its own application evidence. Rank the offers by the required result rather than treating all three as one persistence claim.

References: [PV2][PV3]

Bring separately selected equipment into the physical installation scope

If the platform decision leads to physical equipment that needs installation, Leviathan's Rack & Stack / Colocation service covers agreed equipment mounting, IT cabling, labels and physical installation records. The related service and project inquiry provide the next step for that physical package.

Share a nonconfidential equipment list, site, approved rack and connection requirements, and the receiving team. Scope and availability are confirmed for the engagement. Kubernetes administration, storage design, data movement and application continuation remain with the appointed platform, storage and software owners. This comparison is education, not a field procedure or authorization to alter a system.

References: [L1]