OpenEBS Local PV Device User Guide
This guide will help you to set up and use OpenEBS Local Persistent Volumes backed by Block Devices.
OpenEBS Dynamic Local PV provisioner can create Kubernetes Local Persistent Volumes using block devices available on the node to persist data, hereafter referred to as OpenEBS Local PV Device volumes.
OpenEBS Local PV Device volumes have the following advantages compared to native Kubernetes Local Persistent Volumes.
- Dynamic Volume provisioner as opposed to a Static Provisioner.
- Better management of the Block Devices used for creating Local PVs by OpenEBS NDM. NDM provides capabilities like discovering Block Device properties, setting up Device Filters, metrics collection and ability to detect if the Block Devices have moved across nodes.
OpenEBS Local PV uses volume topology aware pod scheduling enhancements introduced by Kubernetes Local Volumes
OpenEBS Local PV Device volumes will be created using the Block Devices available on the node. You can customize which block devices can be used for creating Local PVs by configuring NDM parameters and/or by creating new StorageClass.
If you have OpenEBS already installed, you can create an example pod that persists data to OpenEBS Local PV Device with following kubectl commands.
Verify using below kubectl commands that example pod is running and is using a OpenEBS Local PV Device.
For a more detailed walkthrough of the setup, follow along the rest of this document.
- Kubernetes 1.12 or higher is required
- OpenEBS 1.0 or higher is required.
If you are running your Kubernetes cluster in an air-gapped environment, make sure the following container images are available in your local repository.
For provisioning Local PV using the block devices, the Kubernetes nodes should have block devices attached to the nodes. The block devices can optionally be formatted and mounted.
The block devices can be any of the following:
- SSD, NVMe or Hard Disk attached to a Kubernetes node (Bare metal server)
- Cloud Provider Disks like EBS or GPD attached to a Kubernetes node (Cloud instances. GKE or EKS)
- Virtual Disks like a vSAN volume or VMDK disk attached to a Kubernetes node (Virtual Machine)
#Customize NDM and Install
You can skip this section if you have already installed OpenEBS.
OpenEBS Dynamic Local Provisioner uses the Block Devices discovered by NDM to create Local PVs. NDM offers some configurable parameters that can be applied during the OpenEBS Installation. Some key configurable parameters available for NDM are:
Prepare to install OpenEBS by providing custom values for configurable parameters.
The location of the OpenEBS Dynamic Local PV provisioner container image.Default value: openebs/provisioner-localpvYAML specification: spec.image on Deployment(localpv-provisioner)Helm key: localprovisioner.image
The location of the OpenEBS NDM DaemonSet container image. NDM DaemonSet helps with discovering block devices attached to a node and creating Block Device Resources.Default value: openebs/node-disk-managerYAML specification: spec.image on DaemonSet(openebs-ndm)Helm key: ndm.image
The location of the OpenEBS NDM Operator container image. NDM Operator helps with allocating Block Devices to Block Device Claims raised by OpenEBS Dynamic Local PV Provisioner.Default value: openebs/node-disk-operatorYAML specification: spec.image on Deployment(openebs-ndm-operator)Helm key: ndmOperator.image
The location of the Provisioner Helper container image. OpenEBS Dynamic Local Provisioner create a Provisioner Helper pod to clean up the data from the block device after the PV has been deleted.Default value: openebs/linux-utilsYAML specification: Environment Variable (CLEANUP_JOB_IMAGE) on Deployment(ndm-operator)Helm key: helper.image
Specify the list of block devices for which BlockDevice CRs must be created. A comma separated values of path regular expressions can be specified.Default value: allYAML specification: data."node-disk-manager.config".filterconfigs.key["path-filter"].include on ConfigMap(openebs-ndm-config)Helm key: ndm.filters.includePaths
Specify the list of block devices for which BlockDevice CRs must not be created. A comma separated values of path regular expressions can be specified.Default value: "loop,fd0,sr0,/dev/ram,/dev/dm-,/dev/md"YAML specification: data."node-disk-manager.config".filterconfigs.key["path-filter"].exclude on ConfigMap(openebs-ndm-config)Helm key: ndm.filters.excludePaths
You can proceed to install OpenEBS either using kubectl or helm using the steps below.
Install using kubectl
If you would like to change the default values for any of the configurable parameters mentioned in the previous step, download the
openebs-operator.yamland make the necessary changes before applying.kubectl apply -f https://openebs.github.io/charts/openebs-operator.yaml
If you would like to use only Local PV (hostpath and device), you can install a lite version of OpenEBS using the following command.
kubectl apply -f https://openebs.github.io/charts/openebs-operator-lite.yaml kubectl apply -f https://openebs.github.io/charts/openebs-lite-sc.yaml
Install using OpenEBS helm charts
If you would like to change the default values for any of the configurable parameters mentioned in the previous step, specify each parameter using the
--set key=value[,key=value]argument to
helm install.helm repo add openebs https://openebs.github.io/chartshelm repo updatehelm install --namespace openebs --name openebs openebs/openebs
#(Optional) Block Device Tagging
You can reserve block devices in the cluster that you would like the OpenEBS Dynamic Local Provisioner to pick up some specific block devices available on the node. You can use the NDM Block Device tagging feature to reserve the devices. For example, if you would like Local SSDs on your cluster for running Mongo stateful application. You can tag a few devices in the cluster with a tag named
You can skip this section if you would like to use default OpenEBS Local PV Device StorageClass created by OpenEBS.
The default Storage Class is called
openebs-device. If the block devices are not formatted, the devices will be formatted with
To create your own StorageClass to customize how Local PV with devices are created. For instance, if you would like to run MongoDB stateful applications with Local PV device, you would want to set the default filesystem as
xfsand/or also dedicate some devices on node that you want to use for Local PV. Save the following StorageClass definition as
local-device-sc.yamlapiVersion: storage.k8s.io/v1kind: StorageClassmetadata:name: local-deviceannotations:openebs.io/cas-type: localcas.openebs.io/config: |- name: StorageTypevalue: device- name: FSTypevalue: xfs- name: BlockDeviceTagvalue: "mongo"provisioner: openebs.io/localreclaimPolicy: DeletevolumeBindingMode: WaitForFirstConsumer
volumeBindingModeMUST ALWAYS be set to
volumeBindingMode: WaitForFirstConsumerinstructs Kubernetes to initiate the creation of PV only after Pod using PVC is scheduled to the node.
FSTypewill take effect only if the underlying block device is not formatted. For instance if the block device is formatted with "Ext4", specifying "XFS" in the storage class will not clear Ext4 and format with XFS. If the block devices are already formatted, you can clear the filesystem information using
wipefs -f -a <device-path>. After the filesystem has been cleared, NDM pod on the node needs to be restarted to update the Block Device.
local-device-sc.yamland update with your desired values for:
Block Device Tag support for Local Volumes was introduced in OpenEBS 1.9.
When specifying the value for BlockDeviceTag, you must already have Block Devices on the nodes labelled with the tag. See Block Device Tagging
Create OpenEBS Local PV Device Storage Class.kubectl apply -f local-device-sc.yaml
Verify that the StorageClass is successfully created.kubectl get sc local-device -o yaml
#Create a PersistentVolumeClaim
The next step is to create a PersistentVolumeClaim. Pods will use PersistentVolumeClaims to request Device backed Local PV from OpenEBS Dynamic Local PV provisioner.
Here is the configuration file for the PersistentVolumeClaim. Save the following PersistentVolumeClaim definition as
local-device-pvc.yamlkind: PersistentVolumeClaimapiVersion: v1metadata:name: local-device-pvcspec:storageClassName: local-deviceaccessModes:- ReadWriteOnceresources:requests:storage: 5G
Create the PersistentVolumeClaimkubectl apply -f local-device-pvc.yaml
Look at the PersistentVolumeClaim:kubectl get pvc local-device-pvc
The output shows that the
Pending. This means PVC has not yet been used by an application pod. The next step is to create a Pod that uses your PersistentVolumeClaim as a volume.NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGElocal-device-pvc Pending local-device 31s
#Using Raw Block Volume
By default, Local PV volume will be provisioned with volumeMode as filesystem. If you would like to use it as Raw Block Volume, specify
Block in the Persistent Volume Claim spec. Here is the configuration file for the PersistentVolumeClaim with Raw Block Volume Support.
Raw Block Volume support was introduced for OpenEBS Local PV OpenEBS 1.5.
#Create Pod to consume OpenEBS Local PV backed by Block Device
Here is the configuration file for the Pod that uses Local PV. Save the following Pod definition to
local-device-pod.yaml.apiVersion: v1kind: Podmetadata:name: hello-local-device-podspec:volumes:- name: local-storagepersistentVolumeClaim:claimName: local-device-pvccontainers:- name: hello-containerimage: busyboxcommand:- sh- -c- 'while true; do echo "`date` [`hostname`] Hello from OpenEBS Local PV." >> /mnt/store/greet.txt; sleep $(($RANDOM % 5 + 300)); done'volumeMounts:- mountPath: /mnt/storename: local-storage
As the Local PV storage classes use
waitForFirstConsumer, do not use
nodeNamein the Pod spec to specify node affinity. If
nodeNameis used in the Pod spec, then PVC will remain in
pendingstate. For more details refer https://github.com/openebs/openebs/issues/2915.
Create the Pod:kubectl apply -f local-device-pod.yaml
Verify that the container in the Pod is running;kubectl get pod hello-local-device-pod
Verify that the container is using the Local PV Devicekubectl describe pod hello-local-device-pod
The output shows that the Pod is running on
Node: gke-user-helm-default-pool-3a63aff5-1tmfand using the persistent volume provided by
local-describe-pvc.Name: hello-local-device-podNamespace: defaultPriority: 0Node: gke-user-helm-default-pool-92abeacf-89nd/10.128.0.16Start Time: Thu, 16 Apr 2020 17:56:04 +0000...Volumes:local-storage:Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)ClaimName: local-device-pvcReadOnly: false...
Look at the PersistentVolumeClaim again to see the details about the dynamically provisioned Local PersistentVolumekubectl get pvc local-device-pvc
The output shows that the
Bound. A new Persistent Volume
pvc-79d25095-eb1f-4028-9843-7824cb82f07fhas been created.NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGElocal-device-pvc Bound pvc-79d25095-eb1f-4028-9843-7824cb82f07f 5G RWO local-device 5m56s
Look at the PersistentVolume details to see where the data is stored. Replace the PVC name with the one that was displayed in the previous step.kubectl get pv pvc-79d25095-eb1f-4028-9843-7824cb82f07f -o yaml
The output shows that the PV was provisioned in response to PVC request
spec.claimRef.name: local-device-pvc.apiVersion: v1kind: PersistentVolumemetadata:name: pvc-79d25095-eb1f-4028-9843-7824cb82f07fannotations:pv.kubernetes.io/provisioned-by: openebs.io/local...spec:accessModes:- ReadWriteOncecapacity:storage: 5GclaimRef:apiVersion: v1kind: PersistentVolumeClaimname: local-device-pvcnamespace: defaultresourceVersion: "291148"uid: 79d25095-eb1f-4028-9843-7824cb82f07f......local:fsType: ""path: /mnt/disks/ssd0nodeAffinity:required:nodeSelectorTerms:- matchExpressions:- key: kubernetes.io/hostnameoperator: Invalues:- gke-user-helm-default-pool-92abeacf-89ndpersistentVolumeReclaimPolicy: DeletestorageClassName: local-devicevolumeMode: Filesystemstatus:phase: Bound
A few important characteristics of a OpenEBS Local PV can be seen from the above output:
spec.nodeAffinityspecifies the Kubernetes node where the Pod using the local volume is scheduled.
spec.local.pathspecifies the path of the block device associated with this PV.
OpenEBS Dynamic Local Provisioner would have created a BlockDeviceClaim to get a BlockDevice from NDM. The BlockDeviceClaim will be having the same name as the PV name. Look at the BlockDeviceClaim details to see which Block Device is being used. Replace the PVC Name in the below command with the PVC name that was displayed in the previous step.kubectl get bdc -n openebs bdc-pvc-79d25095-eb1f-4028-9843-7824cb82f07f
The output shows that the
Bound, and provides the name of the Block Device
blockdevice-d1ef1e1b9dccf224e000c6f2e908c5f2NAME BLOCKDEVICENAME PHASE AGEbdc-pvc-79d25095-eb1f-4028-9843-7824cb82f07f blockdevice-d1ef1e1b9dccf224e000c6f2e908c5f2 Bound 12m
Look at the BlockDevice details to see where the data is stored. Replace the BDC name with the one that was displayed in the previous step.kubectl get bd -n openebs blockdevice-d1ef1e1b9dccf224e000c6f2e908c5f2 -o yaml
The output shows that the BD is on the node
spec.nodeAttributes.nodeName: gke-user-helm-default-pool-92abeacf-89nd.apiVersion: openebs.io/v1alpha1kind: BlockDevicemetadata:name: blockdevice-d1ef1e1b9dccf224e000c6f2e908c5f2namespace: openebs...spec:capacity:logicalSectorSize: 4096physicalSectorSize: 4096storage: 402653184000claimRef:apiVersion: openebs.io/v1alpha1kind: BlockDeviceClaimname: bdc-pvc-79d25095-eb1f-4028-9843-7824cb82f07fnamespace: openebsuid: 8efe7480-9117-4f51-b271-84ee51a94684details:compliance: SPC-4deviceType: diskdriveType: SSDhardwareSectorSize: 4096logicalBlockSize: 4096model: EphemeralDiskphysicalBlockSize: 4096serial: local-ssd-0vendor: Googledevlinks:- kind: by-idlinks:- /dev/disk/by-id/scsi-0Google_EphemeralDisk_local-ssd-0- /dev/disk/by-id/google-local-ssd-0- kind: by-pathlinks:- /dev/disk/by-path/pci-0000:00:04.0-scsi-0:0:1:0filesystem:fsType: ext4mountPoint: /mnt/disks/ssd0nodeAttributes:nodeName: gke-user-helm-default-pool-92abeacf-89ndpartitioned: "No"path: /dev/sdbstatus:claimState: Claimedstate: Active
A few important details from the above Block Device are:
spec.filesystemindicates if the BlockDevice has been formatted and the path where it has been mounted.
- If the block device is pre-formatted as in the above case, the PV will be created with path as
- If the block device is not formatted, it will be formatted with the filesystem specified in the PVC and StorageClass. Default is
- If the block device is pre-formatted as in the above case, the PV will be created with path as
Delete the Pod, the PersistentVolumeClaim and StorageClass that you might have created.
Verify that the PV that was dynamically created is also deleted.
#Backup and Restore
OpenEBS Local Volumes can be backed up and restored along with the application using Velero.
The following steps assume that you already have Velero with Restic integration is configured. If not, please follow the Velero Documentation to proceed with install and setup of Velero. If you encounter any issues or have questions, talk to us on the #openebs channel on the Kubernetes Slack server.
The following steps will help you to prepare and backup the data from the volume created for the example pod (
hello-local-device-pod), with the volume mount (
Prepare the application pod for backup. Velero uses Kubernetes labels to select the pods that need to be backed up. Velero uses annotation on the pods to determine which volumes need to be backed up. For the example pod launched in this guide, you can inform velero to backup by specifying the following label and annotation.kubectl label pod hello-local-device-pod app=test-velero-backupkubectl annotate pod hello-local-device-pod backup.velero.io/backup-volumes=local-storage
Create a Backup using velero.velero backup create bbb-01 -l app=test-velero-backup
Verify that backup is successful.velero backup describe bbb-01 --details
On successful completion of the backup, the output of the backup describe command will show the following:...Restic Backups:Completed:default/hello-local-device-pod: local-storage
Install and Setup Velero, with the same provider where backups were saved. Verify that backups are accessible.velero backup get
The output of should display the backups that were taken successfully.NAME STATUS CREATED EXPIRES STORAGE LOCATION SELECTORbbb-01 Completed 2020-04-25 15:49:46 +0000 UTC 29d default app=test-velero-backup
Restore the application.
Local PVs are created with node affinity. As the node names will change when a new cluster is created, create the required PVC(s) prior to proceeding with restore.
Replace the path to the PVC yaml in the below commands, with the PVC that you have created.kubectl apply -f https://openebs.github.io/charts/examples/local-device/local-device-pvc.yamlvelero restore create rbb-01 --from-backup bbb-01 -l app=test-velero-backup
Verify that application is restored.velero restore describe rbb-01
Depending on the data, it may take a while to initialize the volume. On successful restore, the output of the above command should show:...Restic Restores (specify --details for more information):Completed: 1
Verify that data has been restored. The application pod used in this example, write periodic messages (greetings) to the volume.kubectl exec hello-local-device-pod -- cat /mnt/store/greet.txt
The output will show that backed up data as well as new greetings that started appearing after application pod was restored.Sat Apr 25 15:41:30 UTC 2020 [hello-local-device-pod] Hello from OpenEBS Local PV.Sat Apr 25 15:46:30 UTC 2020 [hello-local-device-pod] Hello from OpenEBS Local PV.Sat Apr 25 16:11:25 UTC 2020 [hello-local-device-pod] Hello from OpenEBS Local PV.
Review the logs of the OpenEBS Local PV provisioner. OpenEBS Dynamic Local Provisioner logs can be fetched using.
If you encounter issues or have a question, file an Github issue, or talk to us on the #openebs channel on the Kubernetes Slack server.