Skip to content

openebs-archive/cstor-csi

This branch is 1 commit ahead of, 8 commits behind develop.

Folders and files

NameName
Last commit message
Last commit date

Latest commit

b490e7e · Feb 25, 2023
Nov 29, 2021
Dec 28, 2021
Mar 16, 2021
Sep 10, 2021
Sep 7, 2020
Sep 10, 2021
Sep 10, 2021
Feb 5, 2020
Jun 30, 2022
Nov 29, 2021
Feb 25, 2023
May 27, 2019
May 27, 2019
May 27, 2019
Jul 16, 2021
May 2, 2020
Jul 12, 2022
Sep 10, 2021
May 22, 2019
May 2, 2020
Mar 8, 2021
Nov 11, 2020
Jun 15, 2021
Sep 10, 2021
Feb 25, 2023
Feb 25, 2023

Repository files navigation

OpenEBS cStor CSI Driver

FOSSA Status Build Status Go Report Slack Community Meetings

CSI driver implementation for OpenEBS cStor storage engine.

Project Status: Beta

The current implementation supports the following for cStor Volumes:

  1. Provisioning and De-provisioning with ext4,xfs filesystems
  2. Snapshots and clones
  3. Volume Expansion
  4. Volume Metrics

Setup OpenEBS cStor CSI Driver

OpenEBS cStor CSI driver components can be installed by using the helm chart or operator yaml. Refer to cstor-operators for detailed usage instructions.

How does it work?

OpenEBS cStor CSI driver comprises of 2 components:

  • A controller component launched as a StatefulSet, implementing the CSI controller services. The Control Plane services are responsible for creating/deleting the required OpenEBS Volume.
  • A node component that runs as a DaemonSet,implementing the CSI node services. The node component is responsible for performing the iSCSI connection management and connecting to the OpenEBS Volume.

The following steps indicate the PV provisioning workflow as it passes through various components.

  1. Create PVC with Storage Class referring to OpenEBS cStor CSI Driver.

  2. Kubernetes will pass the PV creation request to the OpenEBS CSI Controller service via CreateVolume(), as this controller registered with Kubernetes for receiving any requests related to cstor.csi.openebs.io

  3. OpenEBS CSI Controller will create a custom resource called CStorVolumeConfig(CVC) and returns the details of the newly created object back to Kubernetes. The CVCs will be monitored by the cvc-operator. The cvc-operator watches the CVC resources and creates the respected volume specific resources like CStorVolume(CV), Target deployement, CStorVolumeReplicas and K8s service.

    Once the cStor Volume is created, the CVC is updated with the reference to the cStor Volume and change the status on CVC to bound.

  4. Node Component which was waiting on the CVC status to be Bound will proceed to connect to the cStor volume.

Note: While the asynchronous handling of the Volume provisioning is in progress, the application pod may throw some errors like:

  • Waiting for CVC to be bound: Implies volume components are still being created
  • Volume is not ready: Replicas yet to connect to controller: Implies volume components are already created but yet to interact with each other.

On successful completion of the above steps the application pod can be seen in running state.

Contributing

OpenEBS welcomes your feedback and contributions in any form possible.

License

FOSSA Status