このドキュメントでは、ストレージ ポリシーベース管理（SPBM）を使用して、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 の Storage 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 ボリュームの移行で CNS Relocation API を呼び出す
vSphere CSI ドライバによってプロビジョニングされた CNS ボリュームのみを移行する場合は、vSphere でのコンテナ ボリュームの移行の手順に沿って操作します。古いデータストアに CNS ボリュームしかない場合は、この方法が簡単です。
必要に応じてストレージ ポリシーを更新します
vSphere 環境で、古いデータストアを除外するようにストレージ ポリシーを更新します。そうしないと、新しいボリュームと再作成された VM が古いデータストアに割り当てられる可能性があります。