このドキュメントでは、ストレージ ポリシーベースの管理（SPBM）を使用して、1 つの vSphere データストアから別の vSphere データストアにディスクを移行する方法について説明します。
1.29: 一般提供
1.28: プレビュー
1.16: 利用不可
次の種類のストレージを移行できます。
Google Distributed Cloud によって管理されるシステム コンポーネント用のストレージには次のものが含まれます。
管理クラスタと Controlplane V2 ユーザー クラスタのコントロール プレーン ノードで使用されるデータディスク（VMDK ファイル）
すべての管理クラスタとユーザー クラスタ ノードで使用されるブートディスク（VMDK ファイル）
管理クラスタ内の PV/PVC で表され、kubeception ユーザー クラスタのコントロール プレーン コンポーネントで使用される vSphere ボリューム
in-tree vSphere ボリューム プラグインまたは vSphere CSI ドライバによってプロビジョニングされた PV/PVC を使用して、ユーザー クラスタ ワーカーノードにデプロイするワークロード用のストレージ
管理クラスタの前提条件
管理クラスタには HA コントロール プレーンが必要です。管理クラスタに非 HA コントロール プレーンがある場合は、続行する前に HA に移行します。
管理クラスタに HA コントロール プレーンがあることを確認します。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes
ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig ファイルへのパスに置き換えます。
出力に、3 つのコントロール プレーン ノードが表示されていることを確認します。次に例を示します。
admin-cp-1 Ready control-plane,master ... admin-cp-2 Ready control-plane,master ... admin-cp-3 Ready control-plane,master ...
すべてのクラスタの前提条件（管理者とユーザー）
クラスタでノードの自動修復が無効になっている必要があります。ノードの自動修復が有効になっている場合は、ノードの自動修復を無効にします。
クラスタでは、ストレージ ポリシーベースの管理（SPBM）を使用する必要があります。クラスタで SPBM を使用していない場合は、続行する前にストレージ ポリシーを作成します。
クラスタで SPBM が使用されていることを確認します。
kubectl --kubeconfig CLUSTER_KUBECONFIG get onpremadmincluster --namespace kube-system \ -ojson | jq '{datastore: .items[0].spec.vCenter.datastore, storagePolicyName: .items[0].spec.vCenter.storagePolicyName}'（ユーザー クラスタのみ）ノードプールが SPBM を使用していることを確認します。
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremnodepools --namespace USER_CLUSTER_NAME-gke-onprem-mgmt \ -ojson | jq '.items[] | {name: .metadata.name, datastore: .spec.vsphere.datastore, storagePolicyName: .spec.vsphere.storagePolicyName}'次のように置き換えます。
CLUSTER_KUBECONFIG: クラスタの kubeconfig ファイルのパス（管理者またはユーザー）。
ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
USER_CLUSTER_NAME: ユーザー クラスタの名前。
出力で
datastoreフィールドが空で、storagePolicyNameフィールドが空でない場合、クラスタは SPBM を使用しています。クラスタで vSphere in-tree ボリューム プラグインを使用しないでください。
クラスタが古いバージョンの Google Distributed Cloud からアップグレードされた場合は、vSphere in-tree ボリューム プラグインによってプロビジョニングされた PV/PVC がある可能性があります。この種類のボリュームは、kubeception ユーザー クラスタのコントロール プレーン ノードまたはワーカーノードで作成したワークロードで使用されている可能性があります。
すべての PVC とその StorageClass のリスト。
kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc --all-namespaces \ -ojson | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, storageClassName: .spec.storageClassName}'すべての StorageClass を一覧表示し、使用しているプロビジョナーを確認します。
kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass
出力の
PROVISIONER列がkubernetes.io/vsphere-volumeの場合、この StorageClass で作成された PVC は、vSphere in-tree ボリューム プラグインを使用しています。これらの PV/PVC を使用する StatefulSet については、vSphere CSI ドライバに移行してください。
ストレージの移行を行う
Google Distributed Cloud では、次の 2 つのカテゴリのストレージ移行をサポートしています。
VM 用の Storage vMotion は、ノードで実行されている Pod が使用する接続された vSphere CNS ボリュームや、ノードに接続されたこれらの VM CNS ボリュームで使用される VMDK などの VM ストレージを移行します。
CNS ボリュームの再配置は、VM 向けのストレージ vMotion を実行せずに、指定した vSphere CNS ボリュームを互換性のあるデータストアに移動します。
VM のストレージ vMotion を実行する
移行には、vSphere 環境で行う手順と、管理ワークステーションで実行するコマンドが含まれます。
vSphere 環境で、ターゲット データストアをストレージ ポリシーに追加します。
vSphere 環境で、古いデータストアを使用してクラスタ VM を新しいデータストアに移行します。手順については、仮想マシンを新しいコンピューティング リソースとストレージに移行するをご覧ください。
管理ワークステーションで、VM が新しいデータストアに正常に移行されたことを確認します。
クラスタの Machine オブジェクトを取得します。
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml
出力の
status.disksで、VM に接続されているディスクを確認できます。次に例を示します。status: addresses: – address: 172.16.20.2 type: ExternalIP disks: – bootdisk: true datastore: pf-ds06 filepath: me-xvz2ccv28bf9wdbx-2/me-xvz2ccv28bf9wdbx-2.vmdk uuid: 6000C29d-8edb-e742-babc-9c124013ba54 – datastore: pf-ds06 filepath: anthos/gke-admin-nc4rk/me/ci-bluecwang-head-2-data.vmdk uuid: 6000C29e-cb12-8ffd-1aed-27f0438bb9d9
クラスタ内のすべてのマシンのすべてのディスクがターゲット データストアに移行されたことを確認します。
管理ワークステーションで、
gkectl diagnoseを実行して、クラスタが正常であることを確認します。
CNS Relocation API を呼び出して CNS ボリュームを移動します
vSphere CSI ドライバによってプロビジョニングされた CNS ボリュームのみを移動する場合は、vSphere でのコンテナ ボリュームの移行の手順に従います。古いデータストアに CNS ボリュームしかない場合は、この方法が簡単になる可能性があります。
必要に応じてストレージ ポリシーを更新します
vSphere 環境で、ストレージ ポリシーを更新して古いデータストアを除外します。そうしないと、新しいボリュームと再作成された VM が古いデータストアに割り当てられる場合があります。