refactor(readme): refactoring readme (#254)

* adding openebs logo and updating project status
* Updating the GA release version

Signed-off-by: Pawan <pawan@mayadata.io>
This commit is contained in:
Pawan Prakash Sharma 2020-12-14 20:31:38 +05:30 committed by GitHub
parent ef75e6cb2d
commit 43553d6077
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 381 additions and 258 deletions

344
README.md
View file

@ -6,12 +6,13 @@
[![Community Meetings](https://img.shields.io/badge/Community-Meetings-blue)](https://hackmd.io/yJb407JWRyiwLU-XDndOLA?view) [![Community Meetings](https://img.shields.io/badge/Community-Meetings-blue)](https://hackmd.io/yJb407JWRyiwLU-XDndOLA?view)
[![Go Report](https://goreportcard.com/badge/github.com/openebs/zfs-localpv)](https://goreportcard.com/report/github.com/openebs/zfs-localpv) [![Go Report](https://goreportcard.com/badge/github.com/openebs/zfs-localpv)](https://goreportcard.com/report/github.com/openebs/zfs-localpv)
<img width="300" align="right" alt="OpenEBS Logo" src="https://raw.githubusercontent.com/cncf/artwork/master/projects/openebs/stacked/color/openebs-stacked-color.png" xmlns="http://www.w3.org/1999/html">
CSI driver for provisioning Local PVs backed by ZFS and more. CSI driver for provisioning Local PVs backed by ZFS and more.
## Project Status ## Project Status
This project is under active development and with the release of version v0.8.x it is now promoted to beta state. The current implementation supports provisioning and de-provisioning of ZFS Volumes, CSI volume resize, Raw block volumes, Snapshot and Clone. Also, few properties like compression, dedup and recordsize can be provided while provisioning the volumes and can also be changed after provisioning is done. With the release of version 1.2.0, the ZFS-LocalPV is promoted to GA. It is ready for the production, see our [adopters](https://github.com/openebs/openebs/issues/2719).
## Project Tracker ## Project Tracker
@ -225,47 +226,7 @@ The above storage class tells that ZFS pool "zfspv-pool" is available on nodes z
Please note that the provisioner name for ZFS driver is "zfs.csi.openebs.io", we have to use this while creating the storage class so that the volume provisioning/deprovisioning request can come to ZFS driver. Please note that the provisioner name for ZFS driver is "zfs.csi.openebs.io", we have to use this while creating the storage class so that the volume provisioning/deprovisioning request can come to ZFS driver.
#### 2. Create a PVC ##### Scheduler
```
$ cat pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: csi-zfspv
spec:
storageClassName: openebs-zfspv
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4Gi
```
Create a PVC using the storage class created for the ZFS driver. Here, the allocated volume size will be rounded off to the nearest Mi or Gi notation, check the [faq](./docs/faq.md#7-why-the-zfs-volume-size-is-different-than-the-reqeusted-size-in-pvc) section for more details.
#### 3. Check the kubernetes resource is created for the corresponding zfs volume
```
$ kubectl get zv -n openebs
NAME ZPOOL NODE SIZE VOLBLOCKSIZE RECORDSIZE FILESYSTEM
pvc-34133838-0d0d-11ea-96e3-42010a800114 zfspv-pool zfspv-node1 4294967296 4k zfs
```
The ZFS driver will create a ZFS dataset(zvol) on the node zfspv-node1 for the mentioned ZFS pool and the dataset name will same as PV name.
Go to the node zfspv-node1 and check the volume :-
```
$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
zfspv-pool 444K 362G 96K /zfspv-pool
zfspv-pool/pvc-34133838-0d0d-11ea-96e3-42010a800114 96K 4.00G 96K none
```
#### 4. Scheduler
The ZFS driver has a scheduler which will try to distribute the PV across the nodes so that one node should not be loaded with all the volumes. Currently the driver has The ZFS driver has a scheduler which will try to distribute the PV across the nodes so that one node should not be loaded with all the volumes. Currently the driver has
VolumeWeighted scheduling algorithm, in which it will try to find a ZFS pool which has less number of volumes provisioned in it from all the nodes where the ZFS pools are available. VolumeWeighted scheduling algorithm, in which it will try to find a ZFS pool which has less number of volumes provisioned in it from all the nodes where the ZFS pools are available.
@ -293,40 +254,38 @@ parameters:
provisioner: zfs.csi.openebs.io provisioner: zfs.csi.openebs.io
volumeBindingMode: WaitForFirstConsumer volumeBindingMode: WaitForFirstConsumer
``` ```
Please note that once a PV is created for a node, application using that PV will always get scheduled to that particular node only, as PV will be sticky to that node. Please note that once a PV is created for a node, application using that PV will always get scheduled to that particular node only, as PV will be sticky to that node.
The scheduling algorithm by ZFS driver or kubernetes will come into picture only during the deployment time. Once the PV is created, The scheduling algorithm by ZFS driver or kubernetes will come into picture only during the deployment time. Once the PV is created,
the application can not move anywhere as the data is there on the node where the PV is. the application can not move anywhere as the data is there on the node where the PV is.
#### 5. Deploy the application using this PVC #### 2. Create the PVC
``` ```
$ cat fio.yaml $ cat pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1 apiVersion: v1
kind: Pod
metadata: metadata:
name: fio name: csi-zfspv
spec: spec:
restartPolicy: Never storageClassName: openebs-zfspv
containers: accessModes:
- name: perfrunner - ReadWriteOnce
image: openebs/tests-fio resources:
command: ["/bin/bash"] requests:
args: ["-c", "while true ;do sleep 50; done"] storage: 4Gi
volumeMounts:
- mountPath: /datadir
name: fio-vol
tty: true
volumes:
- name: fio-vol
persistentVolumeClaim:
claimName: csi-zfspv
``` ```
After the deployment of the application, we can go to the node and see that the zfs volume is being used Create a PVC using the storage class created for the ZFS driver. Here, the allocated volume size will be rounded off to the nearest Mi or Gi notation, check the [faq](./docs/faq.md#7-why-the-zfs-volume-size-is-different-than-the-reqeusted-size-in-pvc) section for more details.
by the application for reading/writting the data and space is consumed from the ZFS pool.
Also we can check the kubernetes resource for the corresponding zfs volume If we are using the immediate binding in the storageclass then we can check the kubernetes resource for the corresponding zfs volume, other wise in late binding case, we can check the same after pod has been scheduled.
```
$ kubectl get zv -n openebs
NAME ZPOOL NODE SIZE STATUS FILESYSTEM AGE
pvc-34133838-0d0d-11ea-96e3-42010a800114 zfspv-pool zfspv-node1 4294967296 Ready zfs 4s
```
``` ```
$ kubectl describe zv pvc-34133838-0d0d-11ea-96e3-42010a800114 -n openebs $ kubectl describe zv pvc-34133838-0d0d-11ea-96e3-42010a800114 -n openebs
@ -358,7 +317,50 @@ Status:
Events: <none> Events: <none>
``` ```
#### 6. ZFS Property Change The ZFS driver will create a ZFS dataset(or zvol as per fstype in the storageclass) on the node zfspv-node1 for the mentioned ZFS pool and the dataset name will same as PV name.
Go to the node zfspv-node1 and check the volume :-
```
$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
zfspv-pool 444K 362G 96K /zfspv-pool
zfspv-pool/pvc-34133838-0d0d-11ea-96e3-42010a800114 96K 4.00G 96K legacy
```
#### 3. Deploy the application
Create the deployment yaml using the pvc backed by ZFS-LocalPV storage.
```
$ cat fio.yaml
apiVersion: v1
kind: Pod
metadata:
name: fio
spec:
restartPolicy: Never
containers:
- name: perfrunner
image: openebs/tests-fio
command: ["/bin/bash"]
args: ["-c", "while true ;do sleep 50; done"]
volumeMounts:
- mountPath: /datadir
name: fio-vol
tty: true
volumes:
- name: fio-vol
persistentVolumeClaim:
claimName: csi-zfspv
```
After the deployment of the application, we can go to the node and see that the zfs volume is being used
by the application for reading/writting the data and space is consumed from the ZFS pool.
#### 4. ZFS Property Change
ZFS Volume Property can be changed like compression on/off can be done by just simply editing the kubernetes resource for the corresponding zfs volume by using below command : ZFS Volume Property can be changed like compression on/off can be done by just simply editing the kubernetes resource for the corresponding zfs volume by using below command :
``` ```
@ -373,201 +375,8 @@ below command on the node:
zfs get all zfspv-pool/pvc-34133838-0d0d-11ea-96e3-42010a800114 zfs get all zfspv-pool/pvc-34133838-0d0d-11ea-96e3-42010a800114
``` ```
#### 7. Snapshot #### 5. Deprovisioning
We can create a snapshot of a volume which can be used further for creating a clone and for taking a backup. To create a snapshot, we have to first create a snapshotclass just like a storage class.
```yaml
kind: VolumeSnapshotClass
apiVersion: snapshot.storage.k8s.io/v1beta1
metadata:
name: zfspv-snapclass
annotations:
snapshot.storage.kubernetes.io/is-default-class: "true"
driver: zfs.csi.openebs.io
deletionPolicy: Delete
```
Then create the snapshot using the above snapshotclass :
```yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
name: zfspv-snap
spec:
volumeSnapshotClassName: zfspv-snapclass
source:
persistentVolumeClaimName: csi-zfspv
```
Plese note that, you have to create the snapshot in the same namespace where the pvc is created. Check the created snapshot resource, make sure readyToUse field is true, before using this snapshot for any purpose.
Here one thing need to be noted that, when zfs takes the volume snapshot it is not aware of application, so snapshot may not be application-consistent. For application-consistent snapshot it is always recommended to scale down the application before taking the application-consistent volume snapshot. After taking the snapshot we can scale up the application again and proceed further with the clone-creation.
```
$ kubectl get volumesnapshot.snapshot
NAME AGE
zfspv-snap 2m8s
$ kubectl get volumesnapshot.snapshot zfspv-snap -o yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}}
creationTimestamp: "2020-02-25T08:25:51Z"
finalizers:
- snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
- snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
generation: 1
name: zfspv-snap
namespace: default
resourceVersion: "447494"
selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap
uid: 3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
spec:
source:
persistentVolumeClaimName: csi-zfspv
volumeSnapshotClassName: zfspv-snapclass
status:
boundVolumeSnapshotContentName: snapcontent-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
creationTime: "2020-02-25T08:25:51Z"
readyToUse: true
restoreSize: "0"
```
Check the OpenEBS resource for the created snapshot. Check, status should be Ready.
```
$ kubectl get zfssnap -n openebs
NAME AGE
snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd 3m32s
$ kubectl get zfssnap snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd -n openebs -oyaml
apiVersion: openebs.io/v1alpha1
kind: ZFSSnapshot
metadata:
creationTimestamp: "2020-02-25T08:25:51Z"
finalizers:
- zfs.openebs.io/finalizer
generation: 2
labels:
kubernetes.io/nodename: zfspv-node1
openebs.io/persistent-volume: pvc-34133838-0d0d-11ea-96e3-42010a800114
name: snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
namespace: openebs
resourceVersion: "447328"
selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
uid: 6142492c-3785-498f-aa4a-569ec6c0e2b8
spec:
capacity: "4294967296"
fsType: zfs
ownerNodeID: zfspv-node1
poolName: zfspv-pool
volumeType: DATASET
status:
state: Ready
```
we can go to the node and confirm that snapshot has been created :-
```
$ zfs list -t all
NAME USED AVAIL REFER MOUNTPOINT
zfspv-pool 468K 96.4G 96K /zfspv-pool
zfspv-pool/pvc-34133838-0d0d-11ea-96e3-42010a800114 96K 4.00G 96K none
zfspv-pool/pvc-34133838-0d0d-11ea-96e3-42010a800114@snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd 0B - 96K -
```
#### 8. Clone
We can create a clone volume from a snapshot and use that volume for some application. We can create a pvc yaml and mention the snapshot name in the datasource. Please note that for kubernetes version less than 1.17, `VolumeSnapshotDataSource` feature gate needs to be enabled at kubelet and kube-apiserver
```yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: zfspv-clone
spec:
storageClassName: openebs-zfspv
dataSource:
name: zfspv-snap
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4Gi
```
The above yaml says that create a volume from the snapshot zfspv-snap. Applying the above yaml will create a clone volume on the same node where the original volume is present. The newly created clone PV will also be there on the same node where the original PV is there.
Note that the clone PVC should also be of the same size as that of the original volume as right now resize is not supported. Also note that the poolname should also be same, as across the ZPOOL clone is not supported. So, if you are using a separate storageclass for the clone PVC, please make sure it refers to the same ZPOOL.
```
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
csi-zfspv Bound pvc-34133838-0d0d-11ea-96e3-42010a800114 4Gi RWO openebs-zfspv 3h42m
zfspv-clone Bound pvc-e1230d2c-b32a-48f7-8b76-ca335b253dcd 4Gi RWO openebs-zfspv 78s
```
We can see in the above output that zfspv-clone claim has been created and it is bound also. Also, we can check the zfs list on node and verify that clone volume is created.
```
$ zfs list -t all
NAME USED AVAIL REFER MOUNTPOINT
zfspv-pool 444K 96.4G 96K /zfspv-pool
zfspv-pool/pvc-e1230d2c-b32a-48f7-8b76-ca335b253dcd 0B 4G 96K none
zfspv-pool/pvc-34133838-0d0d-11ea-96e3-42010a800114 96K 4.00G 96K none
zfspv-pool/pvc-34133838-0d0d-11ea-96e3-42010a800114@snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd 0B - 96K -
```
The clone volume will have properties same as snapshot properties which are the properties when that snapshot has been created. The ZFSVolume object for the clone volume will be something like below :-
```
$ kubectl describe zv pvc-e1230d2c-b32a-48f7-8b76-ca335b253dcd -n openebs
Name: pvc-e1230d2c-b32a-48f7-8b76-ca335b253dcd
Namespace: openebs
Labels: kubernetes.io/nodename=zfspv-node1
Annotations: <none>
API Version: zfs.openebs.io/v1alpha1
Kind: ZFSVolume
Metadata:
Creation Timestamp: 2019-11-22T09:49:29Z
Finalizers:
zfs.openebs.io/finalizer
Generation: 1
Resource Version: 2881
Self Link: /apis/openebs.io/v1alpha1/namespaces/openebs/zfsvolumes/pvc-e1230d2c-b32a-48f7-8b76-ca335b253dcd
UID: 60bc4df2-0d0d-11ea-96e3-42010a800114
Spec:
Capacity: 4294967296
Fs Type: zfs
Owner Node ID: zfspv-node1
Pool Name: zfspv-pool
Snap Name: pvc-34133838-0d0d-11ea-96e3-42010a800114@snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
Volume Type: DATASET
Status:
State: Ready
Events: <none>
Here you can note that this resource has Snapname field which tells that this volume is created from that snapshot.
```
#### 9. Volume Resize
check [resize doc](docs/resize.md).
#### 10. Raw Block Volume
check [raw block volume](docs/raw-block-volume.md).
#### 11. Backup/Restore
check [backup/restore](docs/backup-restore.md).
#### 12. Deprovisioning
for deprovisioning the volume we can delete the application which is using the volume and then we can go ahead and delete the pv, as part of deletion of pv this volume will also be deleted from the ZFS pool and data will be freed. for deprovisioning the volume we can delete the application which is using the volume and then we can go ahead and delete the pv, as part of deletion of pv this volume will also be deleted from the ZFS pool and data will be freed.
``` ```
@ -577,5 +386,24 @@ $ kubectl delete -f pvc.yaml
persistentvolumeclaim "csi-zfspv" deleted persistentvolumeclaim "csi-zfspv" deleted
``` ```
Features
---
- [x] Access Modes
- [x] ReadWriteOnce
- ~~ReadOnlyMany~~
- ~~ReadWriteMany~~
- [x] Volume modes
- [x] `Filesystem` mode
- [x] `Block` mode
- [x] Supports fsTypes: `ext4`, `btrfs`, `xfs`, `zfs`
- [x] Volume metrics
- [x] [Snapshot](docs/snapshot.md)
- [x] [Clone](docs/clone.md)
- [x] [Volume Resize](docs/resize.md)
- [x] [Raw Block Volume](docs/raw-block-volume.md)
- [x] [Backup/Restore](docs/backup-restore.md)
- [ ] Ephemeral inline volume
## License ## License
[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fopenebs%2Fzfs-localpv.svg?type=large)](https://app.fossa.io/projects/git%2Bgithub.com%2Fopenebs%2Fzfs-localpv?ref=badge_large) [![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fopenebs%2Fzfs-localpv.svg?type=large)](https://app.fossa.io/projects/git%2Bgithub.com%2Fopenebs%2Fzfs-localpv?ref=badge_large)

164
docs/clone.md Normal file
View file

@ -0,0 +1,164 @@
## Prerequisite
For clone, we need to have `VolumeSnapshotDataSource` support, which is in beta in Kubernetes 1.17. If you are using the Kubernetes version less than 1.17, you have to enable the `VolumeSnapshotDataSource` feature gate at kubelet and kube-apiserver.
## Create Clone From Snapshot
We can create a clone volume from a snapshot and use that volume for some application. We can create a PVC YAML and mention the snapshot name in the datasource.
```
$ cat clone.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: zfspv-clone
spec:
storageClassName: openebs-zfspv
dataSource:
name: zfspv-snap
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4Gi
```
The above yaml says that create a volume from the snapshot zfspv-snap. Applying the above yaml will create a clone volume on the same node where the original volume is present. The newly created clone PV will also be there on the same node where the original PV is there. Apply the clone yaml
```
$ kubectl apply -f clone.yaml
persistentvolumeclaim/zfspv-clone created
```
Note that the clone PVC should also be of the same size as that of the original volume. Currently resize is not supported. Also, note that the poolname should also be same, as across the ZPOOL clone is not supported. So, if you are using a separate storageclass for the clone PVC, please make sure it refers to the same ZPOOL.
```
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
csi-zfspv Bound pvc-73402f6e-d054-4ec2-95a4-eb8452724afb 4Gi RWO openebs-zfspv 13m
zfspv-clone Bound pvc-c095aa52-8d09-4bbe-ac3c-bb88a0e7be19 4Gi RWO openebs-zfspv 34s
```
We can see in the above output that zfspv-clone claim has been created and it is bound. Also, we can check the zfs list on node and verify that clone volume is created.
```
$ zfs list -t all
NAME USED AVAIL REFER MOUNTPOINT
test-pool 834K 9.63G 24K /test-pool
test-pool/pvc-73402f6e-d054-4ec2-95a4-eb8452724afb 24K 4.00G 24K /var/lib/kubelet/pods/3862895a-8a67-446e-80f7-f3c18881e391/volumes/kubernetes.io~csi/pvc-73402f6e-d054-4ec2-95a4-eb8452724afb/mount
test-pool/pvc-73402f6e-d054-4ec2-95a4-eb8452724afb@snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd 0B - 24K -
test-pool/pvc-c095aa52-8d09-4bbe-ac3c-bb88a0e7be19 0B 9.63G 24K none
```
The clone volume will have properties same as snapshot properties which are the properties when that snapshot has been created. The ZFSVolume object for the clone volume will be something like below:
```
$ kubectl describe zv pvc-c095aa52-8d09-4bbe-ac3c-bb88a0e7be19 -n openebs
Name: pvc-c095aa52-8d09-4bbe-ac3c-bb88a0e7be19
Namespace: openebs
Labels: kubernetes.io/nodename=e2e1-node2
Annotations: none
API Version: openebs.io/v1alpha1
Kind: ZFSVolume
Metadata:
Creation Timestamp: 2020-02-25T08:34:25Z
Finalizers:
zfs.openebs.io/finalizer
Generation: 1
Resource Version: 448930
Self Link: /apis/openebs.io/v1alpha1/namespaces/openebs/zfsvolumes/pvc-c095aa52-8d09-4bbe-ac3c-bb88a0e7be19
UID: e38a9f9a-fb76-466b-a6f9-8d070e0bec6f
Spec:
Capacity: 4294967296
Fs Type: zfs
Owner Node ID: e2e1-node2
Pool Name: test-pool
Snapname: pvc-73402f6e-d054-4ec2-95a4-eb8452724afb@snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
Volume Type: DATASET
Events: none
```
Here you can note that this resource has Snapname field which tells that this volume is created from that snapshot.
## Create Clone From Volume
We can create a clone volume from an existing volume and use that volume for some application. We can create a PVC YAML and mention the source volume name from where we want to create the clone in the datasource.
```
$ cat clone.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: zfspv-clone
spec:
storageClassName: openebs-zfspv
dataSource:
name: zfspv-pvc
kind: PersistentVolumeClaim
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 4Gi
```
The above yaml says that create a clone from the pvc zfspv-pvc as source. Applying the above yaml will create a clone volume on the same node where the original volume is present. The newly created clone PV will also be there on the same node where the original PV is there. Apply the clone yaml
```
$ kubectl apply -f clone.yaml
persistentvolumeclaim/zfspv-clone created
```
Note that the clone PVC should also be of the same size as that of the original volume. Also, note that the poolname should also be same, as across the ZPOOL clone is not supported. So, if you are using a separate storageclass for the clone PVC, please make sure it refers to the same ZPOOL.
```
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
zfspv-clone Bound pvc-b757fbca-f008-49c6-954e-7ea3e1c1bbc7 4Gi RWO openebs-zfspv 52s
zfspv-pvc Bound pvc-9df1e7ba-bcb1-414a-b318-5084f4f6edeb 4Gi RWO openebs-zfspv 92s
```
We can see in the above output that zfspv-clone claim has been created and it is bound. Also, we can check the zfs list on node and verify that clone volume is created.
```
$ zfs list -t all
NAME USED AVAIL REFER MOUNTPOINT
zfspv-pool 4.26G 497G 24K /zfspv-pool
zfspv-pool/pvc-9df1e7ba-bcb1-414a-b318-5084f4f6edeb 4.25G 502G 130M -
zfspv-pool/pvc-9df1e7ba-bcb1-414a-b318-5084f4f6edeb@pvc-b757fbca-f008-49c6-954e-7ea3e1c1bbc7 0B - 130M -
zfspv-pool/pvc-b757fbca-f008-49c6-954e-7ea3e1c1bbc7 67K 497G 130M -
```
The clone volume will have properties same as source volume properties at the time of creating the clone. The ZFSVolume object for the clone volume will be something like below:
```
$ kubectl describe zv pvc-b757fbca-f008-49c6-954e-7ea3e1c1bbc7 -n openebs
Name: pvc-b757fbca-f008-49c6-954e-7ea3e1c1bbc7
Namespace: openebs
Labels: kubernetes.io/nodename=pawan-node-1
openebs.io/source-volume=pvc-9df1e7ba-bcb1-414a-b318-5084f4f6edeb
Annotations: <none>
API Version: zfs.openebs.io/v1
Kind: ZFSVolume
Metadata:
Creation Timestamp: 2020-12-10T05:00:54Z
Finalizers:
zfs.openebs.io/finalizer
Generation: 2
Resource Version: 53615100
Self Link: /apis/zfs.openebs.io/v1/namespaces/openebs/zfsvolumes/pvc-b757fbca-f008-49c6-954e-7ea3e1c1bbc7
UID: b67ea231-0f5c-4d15-918c-425160706953
Spec:
Capacity: 4294967296
Owner Node ID: pawan-node-1
Pool Name: zfspv-pool
Snapname: pvc-9df1e7ba-bcb1-414a-b318-5084f4f6edeb@pvc-b757fbca-f008-49c6-954e-7ea3e1c1bbc7
Volume Type: ZVOL
Status:
State: Ready
Events: <none>
```
The ZFS-LocalPV driver creates an internal snapshot on the source volume with the name same as clone volume name and then creates the clone from that snapshot. Here you can note that this resource has Snapname field which tells that this volume is created from that internal snapshot.

131
docs/snapshot.md Normal file
View file

@ -0,0 +1,131 @@
## Snapshot
We can create a snapshot of a volume that can be used further for creating a clone and for taking a backup. To create a snapshot, we have to first create a SnapshotClass just like a storage class where you can provide deletionPolicy as Retain or Delete.
```yaml
$ cat snapshotclass.yaml
kind: VolumeSnapshotClass
apiVersion: snapshot.storage.k8s.io/v1beta1
metadata:
name: zfspv-snapclass
annotations:
snapshot.storage.kubernetes.io/is-default-class: "true"
driver: zfs.csi.openebs.io
deletionPolicy: Delete
```
Apply the snapshotclass YAML:
```
$ kubectl apply -f snapshotclass.yaml
volumesnapshotclass.snapshot.storage.k8s.io/zfspv-snapclass created
```
Find a PVC for which snapshot has to be created
```
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
csi-zfspv Bound pvc-73402f6e-d054-4ec2-95a4-eb8452724afb 4Gi RWO openebs-zfspv 2m35s
```
Create the snapshot using the created SnapshotClass for the selected PVC
```
$ cat snapshot.yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
name: zfspv-snap
spec:
volumeSnapshotClassName: zfspv-snapclass
source:
persistentVolumeClaimName: csi-zfspv
```
Apply the snapshot.yaml
```
$ kubectl apply -f snapshot.yaml
volumesnapshot.snapshot.storage.k8s.io/zfspv-snap created
```
Please note that you have to create the snapshot in the same namespace where the PVC is created. Check the created snapshot resource, make sure readyToUsefield is true, before using this snapshot for any purpose.
```
$ kubectl get volumesnapshot.snapshot
NAME AGE
zfspv-snap 2m8s
```
```
$ kubectl get volumesnapshot.snapshot zfspv-snap -o yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}}
creationTimestamp: "2020-02-25T08:25:51Z"
finalizers:
- snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
- snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
generation: 1
name: zfspv-snap
namespace: default
resourceVersion: "447494"
selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap
uid: 3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
spec:
source:
persistentVolumeClaimName: csi-zfspv
volumeSnapshotClassName: zfspv-snapclass
status:
boundVolumeSnapshotContentName: snapcontent-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
creationTime: "2020-02-25T08:25:51Z"
readyToUse: true
restoreSize: "0"
```
Check the OpenEBS resource for the created snapshot. Check, status should be Ready.
```
$ kubectl get zfssnap -n openebs
NAME AGE
snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd 3m32s
```
```
$ kubectl get zfssnap snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd -n openebs -oyaml
apiVersion: openebs.io/v1alpha1
kind: ZFSSnapshot
metadata:
creationTimestamp: "2020-02-25T08:25:51Z"
finalizers:
- zfs.openebs.io/finalizer
generation: 2
labels:
kubernetes.io/nodename: e2e1-node2
openebs.io/persistent-volume: pvc-73402f6e-d054-4ec2-95a4-eb8452724afb
name: snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
namespace: openebs
resourceVersion: "447328"
selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd
uid: 6142492c-3785-498f-aa4a-569ec6c0e2b8
spec:
capacity: "4294967296"
fsType: zfs
ownerNodeID: e2e1-node2
poolName: test-pool
volumeType: DATASET
status:
state: Ready
```
We can go to the node and confirm that snapshot has been created:
```
# zfs list -t all
NAME USED AVAIL REFER MOUNTPOINT
test-pool 818K 9.63G 24K /test-pool
test-pool/pvc-73402f6e-d054-4ec2-95a4-eb8452724afb 24K 4.00G 24K /var/lib/kubelet/pods/3862895a-8a67-446e-80f7-f3c18881e391/volumes/kubernetes.io~csi/pvc-73402f6e-d054-4ec2-95a4-eb8452724afb/mount
test-pool/pvc-73402f6e-d054-4ec2-95a4-eb8452724afb@snapshot-3cbd5e59-4c6f-4bd6-95ba-7f72c9f12fcd 0B - 24K -
```