How to Upgrade your PSO FlexDriver deployment to the latest CSI-based driver
Over the past few months, the Kubernetes FlexDriver codebase has been deprecated and there is a solid shift towards using CSI-based drivers for providing Persistent Volumes to Kubernetes environments.
I’m not going to address the reasons behind that shift here, but suffice to say that all the major storage providers are now using the CSI specification for their persistent storage drivers in Kubernetes.
This is great, but what about those early adopters who installed FlexDriver based drivers?
It’s not the easiest thing to migrate the control of a persistent volume from one driver to another, in fact, it is practically impossible unless you are a Pure Storage customer and are using PSO.
With the latest release of PSO, ie 5.2.0, there is now a way to migrate your PSO FlexDriver created volumes under the control of the PSO CSI driver.
It’s still not simple and it’s a little time consuming, and you do need an outage for your application, but it is possible.
Simply (sic), these are the steps you need to undertake to perform your migration:
- Scale down your applications so that no pods are using the FlexDriver managed PVCs and PVs.
- Uninstall your FlexDriver – don’t worry all your PVs and PVCs will remain and the applications using them won’t notice.
- Install the CSI based driver – now all new PVs will be managed by this new driver.
- Identify your PVs that were created by the FlexDriver.
- Patch the PV definition to ensure it doesn’t get automatically deleted by Kubernetes.
- Delete the PVC and then the PV – sounds scary, but the previous patch command means that underlying volume on the backend storage is retained
- Import the storage volume back into Kubernetes and under the CSI drivers control – this is where you need PSO v5.2.0 or higher…
- Scale back up your applications.
Well that was easy, wasn’t it?
More details on exactly how to perform the steps above are detailed in the PSO GitHub repository documentation.
Now, you may feel a little paranoid about these deletion commands you are running against your precious data, so as a “belt and braces” type activity, you could always make a clone or a snapshot of your underlying storage volumes on your array before you do step 6. But remember to delete these clones when you have completed the migration.