Custom volume provisioning model for interLink providers

[dciangot]

Information are being collected in the following discussion:
https://github.com/interTwin-eu/interLink/discussions/359?sort=new#discussioncomment-12838507

Will open here sub issues to create a step by step path forward.

Implementation reference

Two paths:

• csi driver: custom, taking a description containing fuse script instructions:

spec:
  volumes:
    - name: some-offloadable-volume
       csi: 
         driver: vk.io/interlink
         volume_attributes: 
           script: |
             ...
             sshfs ...

• storage provisioner: on the model of hostpath provisioner https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner/blob/master/examples/hostpath-provisioner/hostpath-provisioner.go
  • same logic of the csi, a readwritemany volume to be shared on multiple pods. leveraging volume attributes https://kubernetes.io/docs/concepts/storage/volume-attributes-classes/#the-volumeattributesclass-api
  • secret and customizations can be passed to the script through env variables

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
 name: hostpath-pvc
spec:
 storageClassName: "hostpath"
 volumeAttributesClassName: "user-home"
 accessModes:
   - ReadWriteMany
 resources:
   requests:
     storage: 1Mi
---
kind: Pod
apiVersion: v1
metadata:
 name: test-pod
spec:
 containers:
 - name: test-pod
   image: gcr.io/google_containers/busybox:1.24
   command:
     - "/bin/sh"
   args:
     - "-c"
     - "touch /mnt/SUCCESS && exit 0 || exit 1"
   volumeMounts:
     - name: hostpath-pvc
       mountPath: "/mnt"
 restartPolicy: "Never"
 volumes:
   - name: hostpath-pvc
     persistentVolumeClaim:
       claimName: hostpath-pvc

csi driver might give more flexibility to the user.

storage provisioner would be more k8s-native compliant, offering a declarative management from the local cluster.