<p>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.</p>
<p>The initial process considered can be seen here - <a href="https://github.com/kubernetes-sigs/aws-efs-csi-driver/tree/master/examples/kubernetes/dynamic_provisioning" rel="nofollow noreferrer">Kube AWS EFS CSI Driver</a> However - the volumes do not reattach.</p>
<p>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:</p>
<pre><code>{{- $name := include &quot;fullname&quot; . -}}
{{- $labels := include &quot;labels&quot; . -}}
{{- range $k, $v := .Values.persistentVolume }}
{{- if $v.enabled }}
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: {{ $v.metadata.name }}-{{ $name }}
  labels:
    name: &quot;{{ $v.metadata.name }}-{{ $name }}&quot;
    {{- $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: &quot;true&quot;
{{- end }}
{{- end }}
</code></pre>
<p>The key var to note above is:</p>
<pre><code>{{ $v.spec.csi.volumeHandle }}
</code></pre>
<p>Whereby the the EFS ID and AP ID can be combined.</p>
<p>Has anyone tried this or something similar in order to establish persistent data volumes, which can be reattached to?</p>

Theo Sweeny
<p>The answer is yes.</p>
<p>When running a statefulset the trick is to swap out the volume claim template, for a persistent volume claim.</p>
<p>The subpath is based on the pod name inside the volume mounts:</p>
<pre><code>  - name: data
    mountPath: /var/rabbitmq
    subPath: $(MY_POD_NAME)
</code></pre>
<p>And in turn mount the persistent volume claims inside the volumes:</p>
<pre><code>  - name: data
    persistentVolumeClaim:
      claimName: data-rabbitmq
</code></pre>
<p>The persistent volume claim is then tied back to the persistent volume, by setting this inside the persistent volume claim:</p>
<pre><code>  volumeName: &lt;pv-name&gt;
</code></pre>
<p>Both the persistent volume and persistent volume claim have their storage classes like so:</p>
<p>storageClassName: &quot;\&quot;\&quot;&quot;</p>
<p>The persistent volume sets both the EFS ID and EFS AP ID like so:</p>
<pre><code>volumeHandle: fs-123::fsap-456
</code></pre>
<p>NB: the EFS AP is created up front via Terraform, not via the AWS EFS CSI driver.</p>
<p>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:</p>
<p>basePath: &quot;/green_infra/queuing/rabbitmq_data&quot;</p>
<p>Happy DevOps :~)</p>
