Defining StorageClass with specific static FSx instance

[robjcook]

Using this aws-fsx-csi-driver is it possible to define a k8s StorageClass so that it uses a specific FSx instance like the following?

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fsx-sc-static
provisioner: fsx.csi.aws.com
parameters:
  fileSystemId: fs-0000
  deploymentType: LUSTRE
reclaimPolicy: Retain

What are the valid values for the parameters for creating a StorageClass with this driver?

[jacobwolfaws]

Can you explain the use case here? Why would you not just use static provisioning as outlined here: https://github.com/kubernetes-sigs/aws-fsx-csi-driver/tree/master/examples/kubernetes/static_provisioning

[robjcook]

It looks my question and use case probably follows a currently existing issue - having a subdirectory provisioning mechanism for this driver would be great

#247

When using the static provisioning where would the definition for any subDir or path need to be defined? From what I understand of the k8s API it would occur at the Workload (Deployment/StatefulSet/Pod) spec level and not possible to be used in PV, PVC, or StorageClass right?

Currently using static provisioning as outlined from the provided examples to deploy a platform on k8s but the developers need a defined StorageClass for set of RWX PVs of their platform that do not need to be 1200 GB FSx instances with dynamic provisioning

EBS driver can not be used as it does not support RWX PVs so what we are doing with the current support in this driver is use an EC2 instance running NFS server acting as a middle man with mounted FSx instance and the nfs-subdir-external-provisioner, having subdirectory provisioning mechanism eliminates this workaround

[jacobwolfaws]

When using the static provisioning where would the definition for any subDir or path need to be defined? From what I understand of the k8s API it would occur at the Workload (Deployment/StatefulSet/Pod) spec level and not possible to be used in PV, PVC, or StorageClass right?

Nope, that's something that would be specified in the PV, I've added an example below. You would need to add the subdirectory to the filesystem prior to using dynamic provisioning to mount the subdirectory. You can create multiple PVs for the same filesystem, each with a different mount_name (just make sure volumeHandle and other identifiers across PVs and PVCs are unique)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: fsx-pv
spec:
  capacity:
    storage: 1200Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  mountOptions:
    - flock
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: fsx.csi.aws.com
    volumeHandle: fs-0199e5a63bd90f796
    volumeAttributes:
      dnsname: fs-0199e5a63bd90f796.fsx.us-east-1.amazonaws.com
      mountname: mount_name/subdirectory_path

that do not need to be 1200 GB FSx instances with dynamic provisioning

Just make sure we're on the same page, dynamically provisioned filesystems can be any size as long as they align with the FSx Lustre sizing requirements for deployment types.

developers need a defined StorageClass for set of RWX PVs of their platform

Is it being a StorageClass a hard requirement or would defined PVs + PVCs work instead? If it's the former, we don't currently offer a solution that would satisfy that need. If it's the latter, the example above should fit what you're looking for.

[jacobwolfaws]

/close

[k8s-ci-robot]

@jacobwolfaws: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.