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