1

I have run some standard Azure IaaS kubernetes clusters for 3 years in production (~ 40 nodes). Because of recent corporate security changes and kubernetes design improvements, in particular the management of CSINodes, I decided to move back from Azure file storages to Longhorn. This scenario has been validated on other clusters.

In production, I would like to move persistent volume from an initial storage class to another one. Let's say storage_class_1 to storage_class_2.

storage_class_1 inherits from Azure File whereas storage_class_2 inherits from longhorn. Persistent volumes are dynamically generated using RabbitMQ operator.

When modifying the CRD definition, no new PV is created and old ones are still bound.

persistence:
  storageClassName: storage_class_2
  storage: 10Gi

I am looking for a way to update the PV without losing any data nor stopping the service. Any idea?

Some technical information: Kubernetes : 1.19.8 Docker : 20.10.2 RabbitMQ Cluster Operator : 1.5.0

Raymond Toh
  • 779
  • 1
  • 8
  • 27
Jack Admin
  • 307
  • 1
  • 13
  • Which version of Kubernetes did you use and how did you set up the cluster? Did you use bare metal installation or some cloud providor? Please attach your CRD definition. What do you mean by update the PV? Did you run `kubectl apply` command after edit the CRD definition? For security protection, create a volume snapshot before you change anything. – Mikołaj Głodziak Sep 21 '21 at 09:33
  • Hi, I have updated the original message with additional information. kubectl apply does update the CRD but do not update persistent volumes. RabbitMQ is in HA mode, deleting an instance then waiting for a new one, doesn't help. I can only create a second instance and update credentials of my subscribers at this stage. – Jack Admin Sep 24 '21 at 12:51
  • Please, post your solution as an answer. – kkopczak Sep 27 '21 at 12:18

1 Answers1

2

I have finally found the right sequence:

  1. Delete one PVC because of the nature of replica sets, volumes are persistent
  2. Remove the corresponding instance
  3. Create a new PVC which refers to the new storage class
  4. The Replicaset will automaticall bind the new instance to this new PVC
  5. Do it for other replicas
Jack Admin
  • 307
  • 1
  • 13