[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[],[],null,["This document explains how to use the StatefulSet CSI Migration Tool to\nmigrate stateful workloads from an in-tree vSphere volume plugin to the vSphere\nCSI Driver in Google Distributed Cloud.\n\nThe following list shows the launch stage for this tool per version:\n\n- v1.0: GA\n- v0.1: [Preview](/products#product-launch-stages)\n\nSupported Google Distributed Cloud versions: 1.30 - 1.28.\n\nOverview\n\nGoogle Distributed Cloud integrates with external block or file storage systems\nthrough VMware vSphere storage, Kubernetes in-tree volume plugins (or\n\"drivers\"), and Container Storage Interface (CSI) drivers.\n\nWith the Kubernetes CSI migration feature enabled by default in 1.15, a\nPersistentVolume backed by the in-tree vSphere volume plugin continues\nfunctioning in a CSI-only environment. The CSI migration feature redirects\nin-tree plugin operation calls to the CSI driver. Because the PersistentVolume\nspec is immutable, it is still backed by the in-tree plugin. The set of\navailable features is the same as for the in-tree volume plugin.\n\nThe full set of CSI features, like Volume Expansion and Volume Snapshot,\nisn't available for such volumes. To take advantage of these features,\nstateful workloads must be completely migrated to CSI by recreating the\nPersistentVolumes backed by the vSphere CSI Driver. You can use the\nCSI migration tool to migrate stateful workloads to CSI and use the full set of\nCSI features.\n\nThis tool provides a way to rolling migrate a StatefulSet's PersistentVolume and\nPersistentVolumeClaim to CSI and does not involve application downtime. This\ntooling takes the backup of Kubernetes resources in a local directory and sets\n`ReclaimPolicy` to `Retain` before migration. So there will be no data loss.\n\nLimitation\n\n- The automated tooling is only supported on Google Distributed Cloud versions that\n are [fully supported](/kubernetes-engine/distributed-cloud/vmware/docs/version-history).\n\n- It only works with StatefulSets. You can run preflight checks using\n the tool to run a few safety checks before using the tools.\n\n```\n./statefulset-csi-migration-tool preflight \\\n --kubeconfig ADMIN_KUBECONFIG \\\n --cluster-name USER_CLUSTER_NAME \\\n --sts-name STS_NAME \\\n --sts-namespace STS_NAMESPACE \\\n --intree-storageclass INTREE_STORAGECLASS \\\n --csi-storageclass CSI_STORAGECLASS\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eADMIN_KUBECONFIG\u003c/var\u003e: the path of your admin cluster\n kubeconfig file.\n\n- \u003cvar translate=\"no\"\u003eUSER_CLUSTER_NAME\u003c/var\u003e: If the StatefulSet is\n running on the user cluster, then provide the user cluster name.\n Skip this flag if the workload is running on the admin cluster.\n\n- \u003cvar translate=\"no\"\u003eSTS_NAME\u003c/var\u003e: name of the StatefulSet.\n\n- \u003cvar translate=\"no\"\u003eSTS_NAMESPACE\u003c/var\u003e: namespace of the StatefulSet.\n\n- \u003cvar translate=\"no\"\u003eINTREE_STORAGECLASS\u003c/var\u003e: the in-tree StorageClass\n name backing the StatefulSet's PersistentVolume.\n\n- \u003cvar translate=\"no\"\u003eCSI_STORAGECLASS\u003c/var\u003e: the CSI StorageClass\n name backing the StatefulSet's PersistentVolume after migration.\n\nDownload\n\nDownload the tool at\n`gs://gke-on-prem-release/statefulset-csi-migration-tool/v1.0/statefulset-csi-migration-tool`.\nNote this tool is in preview.\n\nProcedure\n\nThis section provides the steps needed for migrating StatefulSet from vSphere\nin-tree **vCP** internal provisioner (`kubernetes.io/vsphere-volume`) to vSphere\n**CSI** provisioner (`csi.vsphere.vmware.com`). \n\n```\n./statefulset-csi-migration-tool rolling-migration all \\\n --kubeconfig ADMIN_KUBECONFIG \\\n --cluster-name USER_CLUSTER_NAME \\\n --sts-name STS_NAME \\\n --sts-namespace STS_NAMESPACE \\\n --intree-storageclass INTREE_STORAGECLASS \\\n --csi-storageclass CSI_STORAGECLASS \\\n --working-directory WORKING_DIRECTORY\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eADMIN_KUBECONFIG\u003c/var\u003e: the path of your admin cluster\n kubeconfig file.\n\n- \u003cvar translate=\"no\"\u003eUSER_CLUSTER_NAME\u003c/var\u003e: If the StatefulSet is\n running on the user cluster, then provide the user cluster name.\n Skip this flag if the workload is running on the admin cluster.\n\n- \u003cvar translate=\"no\"\u003eSTS_NAME\u003c/var\u003e: name of the StatefulSet.\n\n- \u003cvar translate=\"no\"\u003eSTS_NAMESPACE\u003c/var\u003e: namespace of the StatefulSet.\n\n- \u003cvar translate=\"no\"\u003eINTREE_STORAGECLASS\u003c/var\u003e: the in-tree StorageClass\n name backing the StatefulSet's PersistentVolume.\n\n- \u003cvar translate=\"no\"\u003eCSI_STORAGECLASS\u003c/var\u003e: the CSI StorageClass\n name backing the StatefulSet's PersistentVolume after migration.\n\n- \u003cvar translate=\"no\"\u003eWORKING_DIRECTORY\u003c/var\u003e: the local directory to\n save the Kubernetes resource spec of StatefulSet and its Pod,\n PersistentVolumeClaim and PersistentVolume. The directory name must be\n unique for each StatefulSet. This directory should be empty or not exist.\n It is ideal to not create this directory so that the tooling can create\n one for you.\n\nThis command performs the following tasks:\n\n1. Takes a backup of the StatefulSet and its dependencies like PersistentVolume,\n PersistentVolumeClaim and Pod replica specs in the local working directory.\n\n2. Deletes the StatefulSet with orphan deletion policy. This step only deletes\n the StatefulSet but does not delete its dependencies like the Pod replicas,\n PersistentVolume and PersistentVolumeClaim.\n\n3. Migrates each Pod to CSI drivers (similar to Option 1), and does the\n following:\n\n a. Sets the PersistentVolume's ReclaimPolicy field as Retain.\n\n b. Deletes the Pod, PersistentVolume and PersistentVolumeClaim.\n\n c. Converts the existing VMDK to FCD.\n\n d. Creates the PersistentVolume, PersistentVolumeClaim and Pod again.\n4. Recreates the StatefulSet, but the PVCTemplate field in its spec points to\n the CSI StorageClass. The StatefulSet controller should map to the orphaned\n replicas again."]]