This article is more than one year old. Older articles may contain outdated content. Check that the information in the page has not become incorrect since its publication.
Kubernetes volume populators are now generally available (GA)! The AnyVolumeDataSource feature
gate is treated as always enabled for Kubernetes v1.33, which means that users can specify any appropriate
custom resource
as the data source of a PersistentVolumeClaim (PVC).
An example of how to use dataSourceRef in PVC:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc1
spec:
...
dataSourceRef:
apiGroup: provider.example.com
kind: Provider
name: provider1
There are four major enhancements from beta.
During the beta phase, contributors to Kubernetes identified potential resource leaks with PersistentVolumeClaim (PVC) deletion while volume population was in progress; these leaks happened due to limitations in finalizer handling. Ahead of the graduation to general availability, the Kubernetes project added support to delete temporary resources (PVC prime, etc.) if the original PVC is deleted.
To accommodate this, we've introduced three new plugin-based functions:
PopulateFn(): Executes the provider-specific data population logic.PopulateCompleteFn(): Checks if the data population operation has finished successfully.PopulateCleanupFn(): Cleans up temporary resources created by the provider-specific functions after data population is completedA provider example is added in lib-volume-populator/example.
For GA, the CSI volume populator controller code gained a MutatorConfig, allowing the specification of mutator functions to modify Kubernetes resources.
For example, if the PVC prime is not an exact copy of the PVC and you need provider-specific information for the driver, you can include this information in the optional MutatorConfig.
This allows you to customize the Kubernetes objects in the volume populator.
Our beta phase highlighted a new requirement: the need to aggregate metrics not just from lib-volume-populator, but also from other components within the provider's codebase.
To address this, SIG Storage introduced a provider metric manager. This enhancement delegates the implementation of metrics logic to the provider itself, rather than relying solely on lib-volume-populator. This shift provides greater flexibility and control over metrics collection and aggregation, enabling a more comprehensive view of provider performance.
During the beta phase, we identified potential resource leaks with PersistentVolumeClaim (PVC) deletion while volume population was in progress, due to limitations in finalizer handling. We have improved the populator to support the deletion of temporary resources (PVC prime, etc.) if the original PVC is deleted in this GA release.
To try it out, please follow the steps in the previous beta blog.
For next step, there are several potential feature requests for volume populator:
To ensure we're building something truly valuable, Kubernetes SIG Storage would love to hear about any specific use cases you have in mind for this feature. For any inquiries or specific questions related to volume populator, please reach out to the SIG Storage community.