CSI volume cloning - Using Container Storage Interface (CSI) | Storage

Overview of CSI volume cloning
- Support limitations
Provisioning a CSI volume clone

Volume cloning duplicates an existing persistent volume to help protect against data loss in OKD. This feature is only available with supported Container Storage Interface (CSI) drivers. You should be familiar with persistent volumes before you provision a CSI volume clone.

Overview of CSI volume cloning

A Container Storage Interface (CSI) volume clone is a duplicate of an existing persistent volume at a particular point in time.

Volume cloning is similar to volume snapshots, although it is more efficient. For example, a cluster administrator can duplicate a cluster volume by creating another instance of the existing cluster volume.

Cloning creates an exact duplicate of the specified volume on the back-end device, rather than creating a new empty volume. After dynamic provisioning, you can use a volume clone just as you would use any standard volume.

No new API objects are required for cloning. The existing dataSource field in the PersistentVolumeClaim object is expanded so that it can accept the name of an existing PersistentVolumeClaim in the same namespace.

Support limitations

By default, OKD supports CSI volume cloning with these limitations:

The destination persistent volume claim (PVC) must exist in the same namespace as the source PVC.
Cloning is supported with a different Storage Class.
- Destination volume can be the same for a different storage class as the source.
- You can use the default storage class and omit storageClassName in the spec.
Support is only available for CSI drivers. In-tree and FlexVolumes are not supported.
CSI drivers might not have implemented the volume cloning functionality. For details, see the CSI driver documentation.

Provisioning a CSI volume clone

When you create a cloned persistent volume claim (PVC) API object, you trigger the provisioning of a CSI volume clone. The clone pre-populates with the contents of another PVC, adhering to the same rules as any other persistent volume. The one exception is that you must add a dataSource that references an existing PVC in the same namespace.

Prerequisites

You are logged in to a running OKD cluster.
Your PVC is created using a CSI driver that supports volume cloning.
Your storage back end is configured for dynamic provisioning. Cloning support is not available for static provisioners.

Procedure

To clone a PVC from an existing PVC:

Create and save a file with the PersistentVolumeClaim object described by the following YAML:

pvc-clone.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-1-clone
  namespace: mynamespace
spec:
  storageClassName: csi-cloning (1)
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  dataSource:
    kind: PersistentVolumeClaim
    name: pvc-1

1	The name of the storage class that provisions the storage back end. The default storage class can be used and `storageClassName` can be omitted in the spec.

Create the object you saved in the previous step by running the following command:
```
$ oc create -f pvc-clone.yaml
```
A new PVC pvc-1-clone is created.
Verify that the volume clone was created and is ready by running the following command:
```
$ oc get pvc pvc-1-clone
```
The pvc-1-clone shows that it is Bound.

You are now ready to use the newly cloned PVC to configure a pod.

Create and save a file with the Pod object described by the YAML. For example:

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: dockerfile/nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: pvc-1-clone (1)

1	The cloned PVC created during the CSI volume cloning operation.

The created Pod object is now ready to consume, clone, snapshot, or delete your cloned PVC independently of its original dataSource PVC.