Migrate FlexVolume to CSI for clusters without data
The FlexVolume storage plug-in is deprecated and no longer supported for new clusters. For existing clusters that use the FlexVolume plug-in, we recommend migrating to the Container Storage Interface (CSI) plug-in. You can migrate by uninstalling the FlexVolume plug-in, installing the CSI plug-in, and updating node pool and existing node configurations. This topic describes this migration process for clusters without data managed by FlexVolume.
Plug-in comparison
The following table compares the CSI and FlexVolume storage plug-ins.
|
Plug-in |
Components |
Kubelet parameter |
References |
|
CSI |
|
The plug-in requires a specific kubelet parameter. Set the kubelet parameter |
|
|
FlexVolume |
|
The plug-in requires a specific kubelet parameter. Set the kubelet parameter |
Use cases
The CSI plug-in is more stable and efficient than the FlexVolume plug-in. We recommend that you migrate from the FlexVolume plug-in to the CSI plug-in if your cluster meets one of the following conditions:
-
No volumes have been mounted in the cluster using FlexVolume.
-
Volumes were previously mounted using FlexVolume, but their associated data has been deleted.
Step 1: Uninstall FlexVolume
-
Log on to the OpenAPI Explorer console and call the UnInstallClusterAddons operation to uninstall the FlexVolume plug-in.
-
ClusterId: Your cluster ID. You can find the cluster ID on the Basic Information page of your cluster.
-
name: Flexvolume.
For more information, see Uninstall cluster add-ons.
-
-
Delete the alicloud-disk-controller and alicloud-nas-controller Deployments.
kubectl delete deploy -n kube-system alicloud-disk-controller alicloud-nas-controller -
Verify that the FlexVolume plug-in is uninstalled.
kubectl get pods -n kube-system | grep 'flexvolume\|alicloud-disk-controller\|alicloud-nas-controller'If the command returns no output, the FlexVolume plug-in is uninstalled.
-
Delete the FlexVolume StorageClass resources. The provisioner for these resources is alicloud/disk.
kubectl delete storageclass alicloud-disk-available alicloud-disk-efficiency alicloud-disk-essd alicloud-disk-ssdExpected output:
storageclass.storage.k8s.io "alicloud-disk-available" deleted storageclass.storage.k8s.io "alicloud-disk-efficiency" deleted storageclass.storage.k8s.io "alicloud-disk-essd" deleted storageclass.storage.k8s.io "alicloud-disk-ssd" deletedThe output indicates that the StorageClasses are deleted.
Step 2: Install CSI
-
If your cluster uses the csi-compatible-controller plug-in, a custom CSI plug-in is already installed. This plug-in is not the standard CSI plug-in. You must delete the custom CSI components by running the following commands before you install the standard CSI plug-in.
kubectl delete deploy csi-provisioner -n kube-system kubectl delete ds csi-plugin -n kube-system kubectl delete csidriver diskplugin.csi.alibabacloud.com nasplugin.csi.alibabacloud.com ossplugin.csi.alibabacloud.comNoteThese deletion operations do not affect existing pods in the cluster. However, after you delete the custom components and before you install the standard CSI plug-in, do not make changes to any pods.
-
If the csi-compatible-controller plug-in is not used, you can directly call the OpenAPI to install the standard CSI plug-in.
-
Log on to the OpenAPI Explorer console and call the InstallClusterAddons operation to install the CSI plug-in.
-
ClusterId: Your cluster ID.
-
name: csi-provisioner.
-
version: The latest version of the CSI plug-in. For more information about CSI versions, see csi-provisioner.
For more information, see Install cluster add-ons.
-
-
Verify that the CSI plug-in is running correctly.
kubectl get pods -n kube-system | grep csiExpected output:
csi-plugin-577mm 4/4 Running 0 3d20h csi-plugin-k9mzt 4/4 Running 0 41d csi-provisioner-6b58f46989-8wwl5 9/9 Running 0 41d csi-provisioner-6b58f46989-qzh8l 9/9 Running 0 6d20hThe output indicates that the CSI plug-in is running as expected.
Step 3: Modify node pool configurations
Node pool configurations depend on the cluster's storage components. After you install the standard CSI components, the configurations of existing node pools are not automatically updated. You must manually modify the node pool configurations to trigger an update. After a successful update, the --enable-controller-attach-detach kubelet parameter for new nodes in the node pool is updated from false to true.
Manually modifying a node pool configuration restarts the kubelet on the nodes in that pool. We recommend that you perform this operation during off-peak hours. After confirming that one node pool is updated correctly, update the remaining node pools in stages.
To trigger the update, you can modify all node pools by either adding an instance type or changing the logon password. This action updates the storage plug-in type in the backend, triggers a refresh of the node initialization script, and ensures that new nodes are configured with the correct parameters.
Alternatively, you can create a new node pool, then gradually scale down and delete the old pools. If you use this method, you can skip the following steps.
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of your cluster. In the left navigation pane, click .
-
On the Node Pools page, find the target node pool and click Edit in the Actions column.
-
In the dialog box that appears, modify the instance type configuration of the node pool and click OK.
NoteThis modification only triggers an update of the backend storage plug-in type. After the update takes effect, you can revert this change.
Step 4: Modify existing node configurations
Apply the following YAML to update kubelet parameters to meet CSI requirements. This DaemonSet sets the --enable-controller-attach-detach parameter to true on existing nodes. After the operation is complete, you can delete the DaemonSet.
Applying the following YAML restarts the kubelet on each node. Evaluate the potential impact on your workloads before proceeding.
kind: DaemonSet
apiVersion: apps/v1
metadata:
name: kubelet-set
spec:
selector:
matchLabels:
app: kubelet-set
template:
metadata:
labels:
app: kubelet-set
spec:
tolerations:
- operator: "Exists"
hostNetwork: true
hostPID: true
containers:
- name: kubelet-set
securityContext:
privileged: true
capabilities:
add: ["SYS_ADMIN"]
allowPrivilegeEscalation: true
image: registry.cn-hangzhou.aliyuncs.com/acs/csi-plugin:v1.26.5-56d1e30-aliyun
imagePullPolicy: "Always"
env:
- name: enableADController
value: "true"
command: ["sh", "-c"]
args:
- echo "Starting kubelet flag set to $enableADController";
ifFlagTrueNum=`cat /host/etc/systemd/system/kubelet.service.d/10-kubeadm.conf | grep enable-controller-attach-detach=$enableADController | grep -v grep | wc -l`;
echo "ifFlagTrueNum is $ifFlagTrueNum";
if [ "$ifFlagTrueNum" = "0" ]; then
curValue="true";
if [ "$enableADController" = "true" ]; then
curValue="false";
fi;
sed -i "s/enable-controller-attach-detach=$curValue/enable-controller-attach-detach=$enableADController/" /host/etc/systemd/system/kubelet.service.d/10-kubeadm.conf;
restartKubelet="true";
echo "current value is $curValue, change to expect "$enableADController;
fi;
if [ "$restartKubelet" = "true" ]; then
/nsenter --mount=/proc/1/ns/mnt systemctl daemon-reload;
/nsenter --mount=/proc/1/ns/mnt service kubelet restart;
echo "restart kubelet";
fi;
while true;
do
sleep 5;
done;
volumeMounts:
- name: etc
mountPath: /host/etc
volumes:
- name: etc
hostPath:
path: /etc
Next steps
After the migration is complete, you can verify that the CSI plug-in is working correctly by creating a dynamically provisioned disk volume. For more information, see Use a dynamically provisioned disk volume.