You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CSI driver implementation for OpenEBS cStor storage engine.
Project Status: Beta
The current implementation supports the following for cStor Volumes:
Provisioning and De-provisioning with ext4,xfs filesystems
Snapshots and clones
Volume Expansion
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.
Create PVC with Storage Class referring to OpenEBS cStor CSI Driver.
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
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.
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.