12.13 Kubernetes VolumeClaimTemplate Management
Kubernetes VolumeClaimTemplate Management dynamically provisions storage for Pods, ensuring persistent data across restarts and scale operations.
Kubernetes VolumeClaimTemplate Management is the practice of correctly configuring and understanding the technical rules governing the volumeClaimTemplates field within a StatefulSet specification, covering how this field's contents are instantiated per ordinal, what happens when the template itself is modified after creation, and how the associated retention policy governs the fate of generated claims across scaling and deletion events.
Instantiation Mechanics
One Claim Generated Per Ordinal Per Template Entry
Each entry within the volumeClaimTemplates array results in one PersistentVolumeClaim being generated for every ordinal the StatefulSet manages, meaning a StatefulSet with two claim template entries and three replicas results in six total generated claims, two per ordinal, each following a naming convention that combines the template name, the StatefulSet name, and the ordinal index.
Fields Copied Into the Generated Claim
The generated claim inherits its accessModes, resources.requests, storageClassName, and any specified labels or annotations directly from the corresponding template entry, with the ordinal-specific name and standard owner-tracking labels applied automatically by the StatefulSet controller on top of these inherited fields.
Immutability After Initial Creation
Template Changes Do Not Retroactively Modify Existing Claims
Once a claim has been generated for a given ordinal, subsequent changes to the corresponding volumeClaimTemplates entry in the StatefulSet specification do not retroactively alter that already-existing claim, meaning a modification such as changing the requested storage size only affects claims generated for new ordinals introduced by a later scale-up, not the claims already bound to existing ordinals.
Manual Reconciliation Required for Existing Claims
Because existing claims are not automatically updated to reflect template changes, bringing already-provisioned claims in line with an updated template, such as applying a new storage size to existing ordinals, requires directly modifying those existing claim objects, where supported by the underlying storage class, rather than relying on the StatefulSet template change to propagate automatically.
Retention Policy Configuration
persistentVolumeClaimRetentionPolicy Field
The persistentVolumeClaimRetentionPolicy field allows explicit configuration of whether generated claims are retained or deleted when the StatefulSet itself is deleted, and separately, whether they are retained or deleted when an ordinal is removed through scaling down, replacing the previously implicit, always-retain default behavior with an explicitly configurable choice.
whenDeleted and whenScaled Behaviors
This policy distinguishes between the whenDeleted behavior, governing claim fate when the entire StatefulSet is removed, and the whenScaled behavior, governing claim fate specifically when an individual ordinal is removed through a replica count reduction, allowing these two distinct scenarios to be configured independently according to differing operational needs.
Claim Template Validation at Creation Time
Rejecting Invalid Template Configurations
Because volumeClaimTemplates entries are validated against the standard PersistentVolumeClaim schema at the time the StatefulSet itself is created, structurally invalid configurations, such as referencing a nonexistent storage class at a syntax level, are caught at this early admission stage rather than surfacing only later when the controller actually attempts to generate claims from the template.
Coordinating Claim Templates With Pod Volume Mounts
Ensuring Volume Names Align Between Template and Mount
The name specified in a volumeClaimTemplates entry must correspond to a volume reference used within the Pod template's container volume mounts, and volumeClaimTemplate management includes ensuring this naming correspondence remains correct and consistent whenever either the claim templates or the Pod template's volume mounts are modified independently of one another.