How do you re-attach a persistent volume to a kubernetes cluster?

Hey there! Quick update for you. This solution should work for you to use an existing volume.

https://github.com/digitalocean/csi-digitalocean/blob/master/examples/kubernetes/pod-single-existing-volume/README.md

Hey there! Quick update for you. This solution should work for you to use an existing volume.

https://github.com/digitalocean/csi-digitalocean/blob/master/examples/kubernetes/pod-single-existing-volume/README.md

Hey there! Quick update for you. This solution should work for you to use an existing volume.

https://github.com/digitalocean/csi-digitalocean/blob/master/examples/kubernetes/pod-single-existing-volume/README.md

Has anyone tried the migration described in https://github.com/digitalocean/csi-digitalocean/blob/master/examples/kubernetes/pod-single-existing-volume/README.md by adding a claimRef that only specifies namespace and name but not uid? E.g.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example
spec:
  accessModes:
  - ReadWriteOnce
  azureDisk:
    ...
  capacity:
    storage: 10Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: caluma-adfinis-minio
    namespace: caluma-adfinis
  persistentVolumeReclaimPolicy: Delete
  storageClassName: default
  volumeMode: Filesystem

@phildougherty thanks for the link!! I had this problem while migrating all my workloads to a new cluster, and solved it by:

1. create the PVC and PV on the new cluster
2. let DO provision the new volume
3. delete the PV on old + new clusters, causing DO volume to detach
4. attach both DO volumes to a separate droplet
5. mount both volumes, manually copy everything over
6. detach both volumes
7. re-create the PV on the new cluster to attach the newly-populated volume

Before that I tried Steps 1-3, but then manually deleted the DO volume from the control panel, then restored a Snapshot I had of the old volume with the “new” auto-generated name, but that failed because apparently the DO provisioner uses GUIDs to track them internally, so even if the names match what’s expected it won’t attach it.

Needless to say, the method you linked looks much simpler so I’ll be trying that next time.

Hello,

At this time it is not possible because of a limitation in the upstream Kubernetes CSI implementation.

Take a look at the following issues: https://github.com/digitalocean/csi-digitalocean/issues/85 https://github.com/kubernetes-csi/external-provisioner/issues/86

There may be a workaround for this that our team is currently testing. If we have success with it I will update this post.

+1

We got similar issue, we snapshot old volume and deployed it on new volume in new cluster. Both needs to be on same datacenter or you try rsync by attaching volume manually to a droplet

+1