AWS EFS CSI Driver Reattachable Persistent Volumes - amazon-web-services

Question

I'm currently running AWS EFS CSI driver v1.37 on EKS v1.20. The idea is to deploy a statefulset application which can persist its volumes post undeploy, and then reattach for subsequent deployments.
The initial process considered can be seen here - Kube AWS EFS CSI Driver However - the volumes do not reattach.
AWS Support have indicated that perhaps the best approach would be to use the static provisioning, whereby creating the EFS Access Points up front, and assigning them via the persistent volume templates similar to:
{{- $name := include "fullname" . -}}
{{- $labels := include "labels" . -}}
{{- range $k, $v := .Values.persistentVolume }}
{{- if $v.enabled }}
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: {{ $v.metadata.name }}-{{ $name }}
labels:
name: "{{ $v.metadata.name }}-{{ $name }}"
{{- $labels | nindent 4 }}
spec:
capacity:
storage: {{ $v.spec.capacity.storage | quote}}
volumeMode: Filesystem
accessModes:
{{- toYaml $v.spec.accessModes | nindent 4 }}
persistentVolumeReclaimPolicy: {{ $v.spec.persistentVolumeReclaimPolicy }}
storageClassName: {{ $v.spec.storageClassName }}
csi:
driver: efs.csi.aws.com
volumeHandle: {{ $v.spec.csi.volumeHandle }}
volumeAttributes:
encryptInTransit: "true"
{{- end }}
{{- end }}
The key var to note above is:
{{ $v.spec.csi.volumeHandle }}
Whereby the the EFS ID and AP ID can be combined.
Has anyone tried this or something similar in order to establish persistent data volumes, which can be reattached to?

Answer 1

The answer is yes.
When running a statefulset the trick is to swap out the volume claim template, for a persistent volume claim.
The subpath is based on the pod name inside the volume mounts:
- name: data
mountPath: /var/rabbitmq
subPath: $(MY_POD_NAME)
And in turn mount the persistent volume claims inside the volumes:
- name: data
persistentVolumeClaim:
claimName: data-rabbitmq
The persistent volume claim is then tied back to the persistent volume, by setting this inside the persistent volume claim:
volumeName: <pv-name>
Both the persistent volume and persistent volume claim have their storage classes like so:
storageClassName: "\"\""
The persistent volume sets both the EFS ID and EFS AP ID like so:
volumeHandle: fs-123::fsap-456
NB: the EFS AP is created up front via Terraform, not via the AWS EFS CSI driver.
And if sharing a single EFS cluster across multiple EKS clusters, the remaining piece of magic is, to ensure the base path inside the storage class is unique for all volumes, across all applications, this is set inside the storage class like so:
basePath: "/green_infra/queuing/rabbitmq_data"
Happy DevOps :~)