Skip to content

Latest commit

 

History

History
118 lines (75 loc) · 6.96 KB

File metadata and controls

118 lines (75 loc) · 6.96 KB

Table of Contents generated with DocToc

Plugin Features

Dynamic Provisioning

Dynamic Provisoning uses persistence volume claim (PVC) to request the Kuberenetes to create the Cinder volume on behalf of user and consumes the volume from inside container.

For usage, refer sample app

Topology

This feature enables driver to consider the topology constraints while creating the volume. For more info, refer Topology Support

  • Enabled by default
  • Supported topology keys: topology.cinder.csi.openstack.org/zone : Availability by Zone
  • allowedTopologies can be specified in storage class to restrict the topology of provisioned volumes to specific zones and should be used as replacement of availability parameter.
  • To disable: set --feature-gates=Topology=false in external-provisioner (container csi-provisioner of csi-cinder-controllerplugin).
    • If using Helm, it can be disabled by setting Values.csi.provisioner.topology: "false"

For usage, refer sample app

Block Volume

Cinder volumes to be exposed inside containers as a block device instead of as a mounted file system. The corresponding CSI feature (CSIBlockVolume) is GA since Kubernetes 1.18.

Prerequisites to use the feature:

  • Make sure the volumeMode is Block in Persistence Volume Claim Spec
  • Make sure the pod consuming the Block device PVC use volumeDevices is used instead of volumeMounts

For usage, refer sample app

Volume Expansion

Driver supports both Offline and Online resize of cinder volumes. Cinder online resize support is available since cinder 3.42 microversion. The same should be supported by underlying OpenStack Cloud to avail the feature.

  • As of kubernetes v1.16, Volume Expansion is a beta feature and enabled by default.
  • Make sure to set allowVolumeExpansion to true in Storage class spec.
  • For usage, refer sample app

Rescan on in-use volume resize

Some hypervizors (like VMware) don't automatically send a new volume size to a Linux kernel, when a volume is in-use. Sending a "1" to /sys/class/block/XXX/device/rescan is telling the SCSI block device to refresh it's information about where it's ending boundary is (among other things) to give the kernel information about it's updated size. When a rescan-on-resize flag is set in a CSI node driver cloud-config [BlockStorage] section, a CSI node driver will rescan block device and verify its size before expanding the filesystem. CSI driver will raise an error, when expected volume size cannot be detected.

Not all hypervizors have a /sys/class/block/XXX/device/rescan location, therefore if you enable this option and your hypervizor doesn't support this, you'll get a warning log on resize event. It is recommended to disable this option in this case.

Volume Snapshots

This feature enables creating volume snapshots and restore volume from snapshot. The corresponding CSI feature (VolumeSnapshotDataSource) is GA since kubernetes 1.20.

  • To avail the feature. deploy the snapshot-controller and CRDs as part of their Kubernetes cluster management process (independent of any CSI Driver) . For more info, refer Snapshot Controller
  • For example on using snapshot feature, refer sample app

Ephemeral Volumes

Two different Kubernetes features allow volumes to follow the Pod's lifecycle: CSI Ephemeral Volumes and Generic Ephemeral Volumes

[DEPRECATED] CSI Ephemeral Volumes

Note: This feature support is deprecated in 1.24 release in favor of Generic Ephemeral Volumes and will no longer be available from 1.27.

This feature allows CSI volumes to be directly embedded in the Pod specification instead of a PersistentVolume. Volumes specified in this way are ephemeral and do not persist across Pod restarts.

  • As of Kubernetes v1.16 this feature is beta so enabled by default.
  • To enable this feature for CSI Driver, volumeLifecycleModes needs to be specified in CSIDriver object. The driver can run in Persistent mode, Ephemeral or in both modes.
  • podInfoOnMount must be true to use this feature.
  • For usage, refer sample app

Generic Ephemeral Volumes

As of Kubernetes v1.21, this is beta feature and enabled by default.

The key design idea is that the parameters for a volume claim are allowed inside a volume source of the Pod. For sample app, refer here

Volume Cloning

This feature enables cloning a volume from existing PVCs in Kubernetes. As of Kubernetes v1.16, volume cloning is beta feature and enabled by default.

Prerequisites:

  • The source PVC must be bound and available (not in use).
  • source and destination PVCs must be in the same namespace.
  • Cloning is only supported within the same Storage Class. Destination volume must be the same storage class as the source

For example, refer sample app

Multi-Attach Volumes

To avail the multiattach feature of cinder, specify the ID/name of cinder volume type that includes an extra-spec capability setting of multiattach=<is> True in storage class type parameter.

This volume type must exist in cinder already (openstack volume type list)

This should enable to attach a volume to multiple hosts/servers simultaneously.

Liveness probe

The liveness probe is a sidecar container that exposes an HTTP /healthz endpoint, which serves as kubelet's livenessProbe hook to monitor health of a CSI driver.

Cinder CSI driver added liveness probe side container by default and refer to manifest and charts for more information.