| Status | Min k8s Version | Max k8s version | external-provisioner Version |
|---|---|---|---|
| Alpha | 1.15 | 1.15 | 1.3 |
| Beta | 1.16 | 1.17 | 1.4 |
| GA | 1.18 | - | 1.6 |
A Clone is defined as a duplicate of an existing Kubernetes Volume. For more information on cloning in Kubernetes see the concepts doc for Volume Cloning. A storage provider that allows volume cloning as a create feature, may choose to implement volume cloning via a control-plan CSI RPC call.
For details regarding the kubernetes API for volume cloning, please see kubernetes concepts.
To implement volume cloning the CSI driver MUST:
- Implement checks for
csi.CreateVolumeRequest.VolumeContentSourcein the plugin'sCreateVolumefunction implementation. - Implement
CLONE_VOLUMEcontroller capability.
It is the responsibility of the storage plugin to either implement an expansion after clone if a provision request size is greater than the source, or allow the external-resizer to handle it. In the case that the plugin does not support resize capability and it does not have the capability to create a clone that is greater in size than the specified source volume, then the provision request should result in a failure.
The Kubernetes CSI development team maintains the external-provisioner which is responsible for detecting requests for a PVC DataSource and providing that information to the plugin via the csi.CreateVolumeRequest. It's up to the plugin to check the csi.CreateVolumeRequest for a VolumeContentSource entry in the CreateVolumeRequest object.
There are no additional side-cars or add on components required.
Volume cloning was promoted to Beta in version 1.16 and GA in 1.18, and as such is enabled by defult for kubernetes versions >= 1.16
In Kubernetes 1.15 this feature was alpha status and required enabling the appropriate feature gate:
--feature-gates=VolumePVCDataSource=true
A trivial example implementation can be found in the csi-hostpath plugin in its implementation of CreateVolume.