README.md

OpenEBS cStor CSI Driver

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.

• Join OpenEBS community on Kubernetes Slack
  • Already signed up? Head to our discussions at #openebs
• Want to raise an issue or help with fixes and features?
  • See open issues
  • See contributing guide
  • See Project Roadmap
  • Want to join our contributor community meetings, check this out.
• Join our OpenEBS CNCF Mailing lists
  • For OpenEBS project updates, subscribe to OpenEBS Announcements
  • For interacting with other OpenEBS users, subscribe to OpenEBS Users

License