データストアを SPBM に移行する

このドキュメントでは、vSphere データストアをストレージ ポリシーベースの管理（SPBM）に移行する方法について説明します。

このページは、ストレージのパフォーマンス、使用状況、費用を構成および管理するストレージ スペシャリストを対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザー ロールとタスクをご覧ください。

1.30: GA
1.29: プレビュー
1.16 およびそれ以前: 利用不可

コンテキスト

クラスタ構成ファイルでデータストアを指定できる場所は 4 か所あります。

• 管理クラスタ: vCenter.datastore

• クラスタレベルのユーザー クラスタ（コントロール プレーンノードとすべてのワーカー ノードプールを含む）: vCenter.datastore

• ユーザー クラスタのコントロール プレーンノード: masterNode.vsphere.datastore

• ユーザー クラスタのワーカー ノードプール: nodePools[i].vsphere.datastore

これらのフィールドの継承は次のとおりです。

adminCluster.vCenter.datastore ->
  userCluster.vCenter.datastore ->
    (userCluster.masterNode.vsphere.datastore and userCluster.nodePools[i].vsphere.datastore)

例:

• userCluster.vCenter.datastore が空の場合、adminCluster.vCenter.datastore から値を継承します。

• userCluster.nodePools[i].vsphere.datastore が空の場合、userCluster.vCenter.datastore から値を継承します。

同様に、ストレージ ポリシーを指定できる場所は 4 か所あります。

• 管理クラスタ vCenter.storagePolicyName

• クラスタレベルのユーザー クラスタ（コントロール プレーンノードとすべてのワーカー ノードプールを含む）: vCenter.storagePolicyName

• ユーザー クラスタのコントロール プレーンノード: masterNode.vsphere.storagePolicyName

• ユーザー クラスタのワーカー ノードプール: nodePools[i].vsphere.storagePolicyName

storagePolicyName フィールドの継承は、datastore フィールドの場合と同じです。

始める前に

• このプロセスは一方向の移行です。以前の状態に戻すことはできません。
• データストアは、設定する新しいストレージ ポリシーに対応している必要があります。
• 高可用性（HA）管理クラスタのみがサポートされます。管理クラスタが非 HA 管理クラスタの場合は、まず管理クラスタを HA に移行する必要があります。

ユーザー クラスタを移行する

移行に使用する手順は、ユーザー クラスタ全体を移行するか、コントロール プレーンノードとワーカー ノードプールを個別に移行するかによって異なります。このオプションを使用すると、コントロール プレーンノードとワーカー ノードプールに異なるストレージ ポリシーを選択できます。

メンテナンスの時間枠を計画する際は、次の点に注意してください。

• クラスタ全体を移行する場合、クラスタの更新は 1 回しか必要ありません。

• コントロール プレーンノードとワーカーノード プールを個別に移行するには、2 回のクラスタ更新が必要です。

クラスタ全体

すべてのコントロール プレーンノードとワーカー ノードプールを含むクラスタ全体を移行する場合は、次の手順を使用します。ユーザー クラスタのバージョンは 1.30 以降である必要があります。

1. ユーザー クラスタ構成ファイルを次のように変更します。

   1. vCenter.storagePolicyName フィールドにストレージ ポリシーの名前を設定します。

   2. 以下のものが指定されているなら、削除するかコメントアウトします。

      • vCenter.datastore フィールド
      • masterNode.vsphere セクション
      • nodepools[i].vsphere.datastore
      • nodepools[i].vsphere.storagePolicyName

   これらの変更を、次の構成例に示します。

   変更前:

   vCenter:
     datastore: ds-1
   

   変更後:

   vCenter:
     storagePolicyName: sp-1
     # datastore: ds-1
   

2. ユーザー クラスタを更新します。

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config USER_CLUSTER_CONFIG
   

   次のように置き換えます。

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

   • USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス。

バンドルされている StorageClass を更新する

クラスタの構成設定を更新してから、バンドルされている StorageClass を更新する必要があります。

1. バンドルされている vsphere-csi-driver の現在のデフォルト StorageClass（standard-rwo という名前）を取得し、storage-class.yaml というローカル ファイルに保存します。

   kubectl get storageclass standard-rwo -oyaml \
       --kubeconfig USER_CLUSTER_KUBECONFIG > storage-class.yaml
   

   USER_CLUSTER_KUBECONFIG は、ユーザー クラスタの kubeconfig ファイルのパスに置き換えます。

2. ファイルに変更を加える必要があるため、万一の場合に備えて storage-class.yaml のコピーを作成します。

   cp storage-class.yaml storage-class.yaml-backup.yaml
   

3. クラスタからデフォルトの StorageClass を削除します。

   kubectl delete storageclass standard-rwo \
       --kubeconfig USER_CLUSTER_KUBECONFIG
   

4. storage-class.yaml の構成を次のように更新します。

   1. 次のフィールドを削除するか、コメントアウトします。

      • parameters.datastoreURL
      • resourceVersion

   2. parameters.storagePolicyName フィールドを追加し、ストレージ ポリシーの名前に設定します。

   これらの変更を、次の構成例に示します。

   変更前:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     datastoreURL: ds//ds-1
   

   変更後:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     storagePolicyName: sp-1
   

5. 変更した StorageClass をユーザー クラスタに適用します。

   kubectl apply -f storage-class.yaml \
       --kubeconfig USER_CLUSTER_KUBECONFIG
   

Kubeception ユーザー クラスタのみ

Kubeception ユーザー クラスタの場合は、管理クラスタ内のユーザー クラスタ コントロール プレーンノードの StorageClass を更新する必要があります。Kubeception クラスタでは、構成フィールド enableControlplaneV2 が false に設定されています。Controlplane V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンはユーザー クラスタ自体で実行されます。Controlplane V2 が有効になっていない場合、ユーザー クラスタのコントロール プレーンは管理クラスタで実行されます。これは、kubeception と呼ばれます。

次のコマンドを実行して、クラスタで Controlplane V2 が有効になっているかどうかを確認します。

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

出力が false の場合は、次の手順で管理クラスタ内のユーザー クラスタ コントロール プレーンノードのデフォルトの StorageClass を更新します。

1. バンドルされている vsphere-csi-driver の現在のデフォルト StorageClass（USER_CLUSTER_NAME-csi という名前）を取得し、storage-class-kubeception.yaml というローカル ファイルに保存します。

   kubectl get storageclass USER_CLUSTER_NAME-csi -oyaml \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG > storage-class-kubeception.yaml
   

   ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig のパスに置き換えます。

2. ファイルに変更を加える必要があるため、万一の場合に備えて storage-class-kubeception.yaml のコピーを作成します。

   cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml
   

3. クラスタからデフォルトの StorageClass を削除します。

   kubectl delete storageclass USER_CLUSTER_NAME-csi \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

4. storage-class-kubeception.yaml の構成を次のように更新します。

   1. 次のフィールドを削除するか、コメントアウトします。

      • parameters.datastoreURL
      • resourceVersion

   2. parameters.storagePolicyName フィールドを追加し、ストレージ ポリシーの名前に設定します。

   これらの変更を、次の構成例に示します。

   変更前:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     datastoreURL: ds//ds-1
   

   変更後:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     storagePolicyName: sp-1
   

5. 変更した StorageClass を管理クラスタに適用します。

   kubectl apply -f storage-class-kubeception.yaml \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

移行後

移行後に新しいノードプールを作成すると、新しいプールには更新されたクラスタに従って継承ルールが適用されます。

たとえば、vCenter.datastore を特定のストレージ ポリシーに移行したとします。

新しいノードプールを作成し、nodePools[i].vsphere.datastore と nodePools[i].vsphere.storagePolicyName の両方を空のままにすると、新しいノードプールは vCenter.storagePolicyName で指定されたストレージ ポリシーを継承します。

ノードごとに移行する

コントロール プレーンノードとワーカー ノードプールを個別に移行する場合は、次の手順を使用します。

1. バージョン 1.29 のみ: 現在のクラスタ構成を取得します。ユーザー クラスタのバージョンが 1.30 以降の場合は、この手順は必要ありません。

   gkectl get-config cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --cluster-name USER_CLUSTER_NAME \
     --output-dir ./gen-files
   

   次のように置き換えます。

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

   • USER_CLUSTER_NAME: ユーザー クラスタの名前。

   ./gen-files で、user-cluster.yaml を見つけます。

   構成ファイルの取得の詳細については、クラスタから構成ファイルを生成するをご覧ください。

   生成された構成ファイルには、次の例に示すように、クラスタ、masterNode（コントロール プレーンノード用）、nodepools（ワーカーノード用）の各レベルで datastore 名が設定されています。

   apiVersion: v1
   kind: UserCluster
   ...
   # VCenter config in cluster level:
   vCenter:
     datastore: ds-1
   ...
   # VCenter config in master node level:
   masterNode:
     vsphere:
       datastore: ds-1
   ...
   # VCenter config in nodepool level:
   nodepools:
   - name: pool-1
     vsphere:
       datastore: ds-1
   - name: pool-2
     vsphere:
       datastore: ds-1
   

コントロール プレーンノードを移行する

コントロール プレーンノードを移行する手順は次のとおりです。

1. ユーザー クラスタの構成ファイルを次のように変更します。

   • masterNode.vsphere.storagePolicyName フィールドにストレージ ポリシーの名前を設定します。
   • masterNode.vsphere.datastore フィールドを削除するか、コメントアウトします。

   これらの変更を、次の構成例に示します。

   変更前:

   masterNode:
     vsphere:
       datastore: ds-1
   

   変更後:

   masterNode:
     vsphere:
       # datastore: ds-1
       storagePolicyName: sp-1
   

2. ユーザー クラスタを更新します。

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config USER_CLUSTER_CONFIG
   

   次のように置き換えます。

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

   • USER_CLUSTER_CONFIG: ユーザー クラスタの構成ファイルのパス。

   更新コマンドが完了するまで待ってから、ノードプールを更新します。

ノードプールを移行する

すべてのノードプールを移行する手順は次のとおりです。

1. ユーザー クラスタの構成ファイルを次のように変更します。

   • 各 nodePools[i].vsphere.storagePolicyName フィールドにストレージ ポリシーの名前を設定します。
   • 各 nodePools[i].vsphere.datastore フィールドを削除するか、コメントアウトします。

   これらの変更を、次の構成例に示します。

   変更前:

   nodepools:
   - name: pool-1
     vsphere:
       datastore: ds-1
   - name: pool-2
     vsphere:
       datastore: ds-1
   

   変更後:

   nodepools:
   - name: pool-1
     vsphere:
       # datastore: ds-1
       storagePolicyName: sp-1
   - name: pool-2
     vsphere:
       # datastore: ds-1
       storagePolicyName: sp-1
   

2. ユーザー クラスタを更新します。

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config USER_CLUSTER_CONFIG
   

必要に応じて、クラスタレベルでストレージ ポリシーを更新する

ユーザー クラスタの場合、クラスタレベルの vCenter セクションの datastore フィールドと storagePolicyName フィールドは、masterNode セクションと nodepools セクションで使用されるデフォルト値です。上記の手順を完了すると、クラスタレベルの vCenter datastore と storagePolicyName の設定は、クラスタ コンポーネントで使用されなくなります。クラスタレベルの vCenter セクションはそのままにするか、masterNode および nodepools と一致するように更新します。

設定をそのままにする場合は、クラスタレベルの vCenter セクションの上に、この設定は masterNode セクションと nodepools セクションの設定によってオーバーライドされ、無視されるというコメントを追加することをおすすめします。

必要に応じて、クラスタレベルの vCenter セクションを masterNode および nodepools セクションと一致するように変更し、次の手順でクラスタを更新できます。

1. ユーザー クラスタ構成ファイルを次のように変更します。

   • vCenter.storagePolicyName フィールドにストレージ ポリシーの名前を設定します。
   • vCenter.datastore フィールドを削除するか、コメントアウトします。

2. ユーザー クラスタを更新します。

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config USER_CLUSTER_CONFIG
   

   この更新コマンドはクラスタに変更を加えませんが、サーバーサイド（OnPremUserCluster）の vCenter.datastore および vCenter.storagePolicyName フィールドを更新します。

バンドルされている StorageClass を更新する

構成設定を更新したら、バンドルされている StorageClass を更新する必要があります。

1. バンドルされている vsphere-csi-driver の現在のデフォルト StorageClass（standard-rwo という名前）を取得し、storage-class.yaml というローカル ファイルに保存します。

   kubectl get storageclass standard-rwo -oyaml \
       --kubeconfig USER_CLUSTER_KUBECONFIG > storage-class.yaml
   

   USER_CLUSTER_KUBECONFIG は、ユーザー クラスタの kubeconfig ファイルのパスに置き換えます。

2. ファイルに変更を加える必要があるため、万一の場合に備えて storage-class.yaml のコピーを作成します。

   cp storage-class.yaml storage-class.yaml-backup.yaml
   

3. クラスタからデフォルトの StorageClass を削除します。

   kubectl delete storageclass standard-rwo \
       --kubeconfig USER_CLUSTER_KUBECONFIG
   

4. storage-class.yaml の構成を次のように更新します。

   1. 次のフィールドを削除するか、コメントアウトします。

      • parameters.datastoreURL
      • resourceVersion

   2. parameters.storagePolicyName フィールドを追加し、ストレージ ポリシーの名前に設定します。

   これらの変更を、次の構成例に示します。

   変更前:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     datastoreURL: ds//ds-1
   

   変更後:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     storagePolicyName: sp-1
   

5. 変更した StorageClass をユーザー クラスタに適用します。

   kubectl apply -f storage-class.yaml \
       --kubeconfig USER_CLUSTER_KUBECONFIG
   

Kubeception ユーザー クラスタのみ

Kubeception ユーザー クラスタの場合は、管理クラスタ内のユーザー クラスタ コントロール プレーンノードの StorageClass を更新する必要があります。Kubeception クラスタでは、構成フィールド enableControlplaneV2 が false に設定されています。Controlplane V2 が有効になっている場合、ユーザー クラスタのコントロール プレーンはユーザー クラスタ自体で実行されます。Controlplane V2 が有効になっていない場合、ユーザー クラスタのコントロール プレーンは管理クラスタで実行されます。これは、kubeception と呼ばれます。

次のコマンドを実行して、クラスタで Controlplane V2 が有効になっているかどうかを確認します。

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

出力が false の場合は、次の手順で管理クラスタ内のユーザー クラスタ コントロール プレーンノードのデフォルトの StorageClass を更新します。

1. バンドルされている vsphere-csi-driver の現在のデフォルト StorageClass（USER_CLUSTER_NAME-csi という名前）を取得し、storage-class-kubeception.yaml というローカル ファイルに保存します。

   kubectl get storageclass USER_CLUSTER_NAME-csi -oyaml \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG > storage-class-kubeception.yaml
   

   ADMIN_CLUSTER_KUBECONFIG は、管理クラスタの kubeconfig のパスに置き換えます。

2. ファイルに変更を加える必要があるため、万一の場合に備えて storage-class-kubeception.yaml のコピーを作成します。

   cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml
   

3. クラスタからデフォルトの StorageClass を削除します。

   kubectl delete storageclass USER_CLUSTER_NAME-csi \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

4. storage-class-kubeception.yaml の構成を次のように更新します。

   1. 次のフィールドを削除するか、コメントアウトします。

      • parameters.datastoreURL
      • resourceVersion

   2. parameters.storagePolicyName フィールドを追加し、ストレージ ポリシーの名前に設定します。

   これらの変更を、次の構成例に示します。

   変更前:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     datastoreURL: ds//ds-1
   

   変更後:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
     name: standard-rwo
   Parameters:
     ...
     storagePolicyName: sp-1
   

5. 変更した StorageClass を管理クラスタに適用します。

   kubectl apply -f storage-class-kubeception.yaml \
       --kubeconfig ADMIN_CLUSTER_KUBECONFIG
   

管理クラスタを移行する

管理クラスタもストレージ ポリシー名で更新されていることを確認します。

1. 管理クラスタの構成ファイルを次のように変更します。

   • vCenter.datastore フィールドを削除するか、コメントアウトします。
   • vCenter.storagePolicyName フィールドにストレージ ポリシーの名前を設定します。

2. 管理クラスタを更新します。

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config ADMIN_CLUSTER_CONFIG
   

   次のように置き換えます。

   • ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルへのパス。
   • ADMIN_CLUSTER_CONFIG: 管理クラスタの構成ファイルへのパス。

SPBM を使用したストレージの移行

データストアから SPBM への移行後、クラスタは SPBM を使用するようになります。ただし、この移行では、古いデータストアからストレージ ワークロード（マシン データディスクやコンテナ ボリュームなど）は移動されません。

ストレージ ワークロードを移動するには、ストレージ ポリシーベースの管理によるストレージの移行をご覧ください。