Skip to content

Latest commit

 

History

History
84 lines (62 loc) · 4.23 KB

README.md

File metadata and controls

84 lines (62 loc) · 4.23 KB

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