#Shoot CSI features

The following details the possibilities the OSC Container Storage Interface (CSI) offers to customize the creation of Persistent Volumes.

#Volume extension

It is possible to extend an existing Persistent Volume. Shrinking a volume is not supported.

To extend a volume, follow the following steps:

• Edit the volume's PersistentVolumeClaim (PVC) object, and change the storage resource request:

  apiVersion: v1
  kind: PersistentVolumeClaim
  spec:
    resources:
      requests:
        # storage: 4Gi
        storage: 10Gi

• The PVC's status reflects the resize request (the spec contains the extended size, the status still shows the original size):

  apiVersion: v1
  kind: PersistentVolumeClaim
  spec:
    resources:
      requests:
        storage: 10Gi
  status:
    phase: Bound
    capacity:
      storage: 4Gi
    conditions:
      - type: Resizing
        status: 'True'
        lastProbeTime: null
        lastTransitionTime: '2025-03-27T09:51:56Z'
      - type: FileSystemResizePending
        status: 'True'
        lastProbeTime: null
        lastTransitionTime: '2025-03-27T09:51:56Z'
        message: >-
          Waiting for user to (re-)start a pod to finish file system resize of
          volume on node.

• The Pod using the PVC needs to re-initialize its storage. A simple Pod restart is not sufficient. One of the following methods can be used:

  • Preferred Method: Cordon the Pod's Node and delete the Pod. This will force the Pod to be started on a different Node, during which the storage will be re-initialized. After the new Pod is started, uncordon the cordoned Node.

  • Alternative Method: Delete the VolumeAttachment object of the extended volume and delete the Pod.

    Warning

    Using this method may cause inconsistency or disruption in the application using the volume.

    Get the PersistentVolume used by the change PVC:

    $ kubectl get pvc \
        -n default \
        -o custom-columns='PV:.spec.volumeName' \
        my-changed-volume
    PV
    csi-onmetal-xxxxxxxxxx

    Get the VolumeAttachment for the identified Volume:

    $ kubectl get volumeattachments \
        -o custom-columns='NAME:.metadata.name,PV:.spec.source.persistentVolumeName' \
        | grep csi-onmetal-xxxxxxxxxx
    NAME                                                                   PV
    csi-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx   csi-onmetal-xxxxxxxxxx

    Delete the identified VolumeAttachment and the Pod.

  After the Pod is restarted, the sizes both in spec and status will reflect the extended size.

  apiVersion: v1
  kind: PersistentVolumeClaim
  spec:
    resources:
      requests:
        storage: 10Gi
  status:
    phase: Bound
    capacity:
      storage: 10Gi

#Custom storage class with more inodes

Apply following manifest to create a storage class which allows higher number of inodes per volume.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: <name>
provisioner: csi.onmetal.de
parameters:
  mkfs_options: '-i <bytes/inode ratio>'
  type: fast
  volume_pool: <region>
reclaimPolicy: Delete
allowVolumeExpansion: false
volumeBindingMode: WaitForFirstConsumer

#Custom storage class with XFS filesystem

Apply following manifest to create a storage class which will use the XFS filesystem for the volumes:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: <name>
provisioner: csi.onmetal.de
parameters:
  fstype: xfs
  type: fast
  volume_pool: <region>
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

#Provisioning a Persistent Volume without a filesystem

It is possible to provision a Persistent Volume with a bare block device, created without any filesystem. This feature can be used for example with certain databases, which create their own on-disk structures.

To create such volume, set the PVC's volumeMode to Block:

apiVersion: v1
kind: PersistentVolumeClaim
spec:
  volumeMode: Block