<p>We have a <code>PVC</code> that is written to by many <code>k8s</code> <code>cronjobs</code>. We'd like to periodically copy this data locally. Ordinarily one would use <code>kubectl cp</code> to do such tasks, but since there's no actively running pod with the <code>PVC</code> mounted, this is not possible.</p>
<p>We've been using a modified version of this gist script <a href="https://gist.github.com/yuanying/3aa7d59dcce65470804ab43def646ab6" rel="nofollow noreferrer">kubectl-run-with-pvc.sh</a> to create a temporary pod (running <code>sleep 300</code>) and then <code>kubectl cp</code> from this temporary pod to get the <code>PVC</code> data. This &quot;works&quot; but seems kludgey.</p>
<p>Is there a more elegant way to achieve this?</p>

colm.anseo
<p>May I propose to use NFS instead of PVC?</p>
<p>If you do not have an NFS server, you can run one inside k8s cluster using this image @ <a href="https://hub.docker.com/r/itsthenetwork/nfs-server-alpine" rel="nofollow noreferrer">https://hub.docker.com/r/itsthenetwork/nfs-server-alpine</a>. The in-cluster NFS server indeed uses PVC for its storage but your pods should mount using NFS instead.</p>
<p>Meaning, from <code>pod --&gt; PVC</code> to <code>pod --&gt; NFS --&gt; PVC</code>.</p>
<p>Here is the script that I quite often use to created dedicated in-cluster NFS servers (just modify the variables at the top of the script accordingly):</p>
<pre><code>export NFS_NAME=&quot;nfs-share&quot;
export NFS_SIZE=&quot;10Gi&quot;
export NFS_SERVER_IMAGE=&quot;itsthenetwork/nfs-server-alpine:latest&quot;
export STORAGE_CLASS=&quot;thin-disk&quot;

kubectl apply -f - &lt;&lt;EOF
apiVersion: v1
kind: Service
metadata:
  name: ${NFS_NAME}
  labels:
    app.kubernetes.io/name: nfs-server
    app.kubernetes.io/instance: ${NFS_NAME}
spec:
  ports:
  - name: tcp-2049
    port: 2049
    protocol: TCP
  - name: udp-111
    port: 111
    protocol: UDP
  selector:
    app.kubernetes.io/name: nfs-server
    app.kubernetes.io/instance: ${NFS_NAME}
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app.kubernetes.io/name: nfs-server
    app.kubernetes.io/instance: ${NFS_NAME}
  name: ${NFS_NAME}
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: ${NFS_SIZE}
  storageClassName: ${STORAGE_CLASS}
  volumeMode: Filesystem
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ${NFS_NAME}
  labels:
    app.kubernetes.io/name: nfs-server
    app.kubernetes.io/instance: ${NFS_NAME}
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: nfs-server
      app.kubernetes.io/instance: ${NFS_NAME}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: nfs-server
        app.kubernetes.io/instance: ${NFS_NAME}
    spec:
      containers:
      - name: nfs-server
        image: ${NFS_SERVER_IMAGE}
        ports:
        - containerPort: 2049
          name: tcp
        - containerPort: 111
          name: udp
        securityContext:
          privileged: true
        env:
        - name: SHARED_DIRECTORY
          value: /nfsshare
        volumeMounts:
        - name: pvc
          mountPath: /nfsshare
      volumes:
      - name: pvc
        persistentVolumeClaim:
          claimName: ${NFS_NAME}
EOF
</code></pre>
<p>To mount the NFS inside your pod, first you need to get its service IP:</p>
<pre><code>export NFS_NAME=&quot;nfs-share&quot;
export NFS_IP=$(kubectl get --template={{.spec.clusterIP}} service/$NFS_NAME)
</code></pre>
<p>Then:</p>
<pre><code>  containers:
    - name: apache
      image: apache
      volumeMounts:
        - mountPath: /var/www/html/
          name: nfs-vol
          subPath: html
  volumes:
    - name: nfs-vol
      nfs: 
        server: $NFS_IP
        path: /
</code></pre>
<p>This way, not only you have a permanently running pod (which is the NFS server pod) for you to do the <code>kubectl cp</code>, you also have the opportunity to mount the same NFS volume to multiple pods concurrently since NFS does not have the single-mount restriction that most PVC drivers have.</p>
<p>N.B: I have been using this in-cluster NFS server technique for almost 5 years with no issues supporting production-grade traffic volumes.</p>
