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

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

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

1.30: GA
1.29: プレビュー
1.16 以前: 利用不可

コンテキスト

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

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

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 か所あります。

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 と呼ばれます。

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

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

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

  1. バンドルされた vsphere-csi-driver（USER_CLUSTER_NAME-csi という名前）の現在のデフォルト StorageClass を取得し、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 と呼ばれます。

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

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

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

  1. バンドルされた vsphere-csi-driver（USER_CLUSTER_NAME-csi という名前）の現在のデフォルト StorageClass を取得し、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 を使用しています。ただし、移行では、古いデータストアからストレージ ワークロード（マシンデータディスクやコンテナ ボリュームなど）は移動されません。

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