このドキュメントでは、vSphere データストアをストレージ ポリシーベースの管理(SPBM)に移行する方法について説明します。
このページは、ストレージのパフォーマンス、使用状況、費用を構成および管理するストレージ スペシャリストを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
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 以降である必要があります。
ユーザー クラスタ構成ファイルを次のように変更します。
vCenter.storagePolicyName
フィールドにストレージ ポリシーの名前を設定します。以下のものが指定されているなら、削除するかコメントアウトします。
vCenter.datastore
フィールドmasterNode.vsphere
セクションnodepools[i].vsphere.datastore
nodepools[i].vsphere.storagePolicyName
これらの変更を、次の構成例に示します。
変更前:
vCenter: datastore: ds-1
変更後:
vCenter: storagePolicyName: sp-1 # datastore: ds-1
ユーザー クラスタを更新します。
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG
次のように置き換えます。
ADMIN_CLUSTER_KUBECONFIG
: 管理クラスタの kubeconfig ファイルのパス。USER_CLUSTER_CONFIG
: ユーザー クラスタの構成ファイルのパス。
バンドルされている StorageClass
を更新する
クラスタの構成設定を更新してから、バンドルされている StorageClass
を更新する必要があります。
バンドルされている
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 ファイルのパスに置き換えます。ファイルに変更を加える必要があるため、万一の場合に備えて
storage-class.yaml
のコピーを作成します。cp storage-class.yaml storage-class.yaml-backup.yaml
クラスタからデフォルトの
StorageClass
を削除します。kubectl delete storageclass standard-rwo \ --kubeconfig USER_CLUSTER_KUBECONFIG
storage-class.yaml
の構成を次のように更新します。次のフィールドを削除するか、コメントアウトします。
parameters.datastoreURL
resourceVersion
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
変更した
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
を更新します。
バンドルされている
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 のパスに置き換えます。ファイルに変更を加える必要があるため、万一の場合に備えて
storage-class-kubeception.yaml
のコピーを作成します。cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml
クラスタからデフォルトの
StorageClass
を削除します。kubectl delete storageclass USER_CLUSTER_NAME-csi \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
storage-class-kubeception.yaml
の構成を次のように更新します。次のフィールドを削除するか、コメントアウトします。
parameters.datastoreURL
resourceVersion
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
変更した
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.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
コントロール プレーンノードを移行する
コントロール プレーンノードを移行する手順は次のとおりです。
ユーザー クラスタの構成ファイルを次のように変更します。
masterNode.vsphere.storagePolicyName
フィールドにストレージ ポリシーの名前を設定します。masterNode.vsphere.datastore
フィールドを削除するか、コメントアウトします。
これらの変更を、次の構成例に示します。
変更前:
masterNode: vsphere: datastore: ds-1
変更後:
masterNode: vsphere: # datastore: ds-1 storagePolicyName: sp-1
ユーザー クラスタを更新します。
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG
次のように置き換えます。
ADMIN_CLUSTER_KUBECONFIG
: 管理クラスタの kubeconfig ファイルのパス。USER_CLUSTER_CONFIG
: ユーザー クラスタの構成ファイルのパス。
更新コマンドが完了するまで待ってから、ノードプールを更新します。
ノードプールを移行する
すべてのノードプールを移行する手順は次のとおりです。
ユーザー クラスタの構成ファイルを次のように変更します。
- 各
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
- 各
ユーザー クラスタを更新します。
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
セクションと一致するように変更し、次の手順でクラスタを更新できます。
ユーザー クラスタ構成ファイルを次のように変更します。
vCenter.storagePolicyName
フィールドにストレージ ポリシーの名前を設定します。vCenter.datastore
フィールドを削除するか、コメントアウトします。
ユーザー クラスタを更新します。
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG
この更新コマンドはクラスタに変更を加えませんが、サーバーサイド(
OnPremUserCluster
)のvCenter.datastore
およびvCenter.storagePolicyName
フィールドを更新します。
バンドルされている StorageClass
を更新する
構成設定を更新したら、バンドルされている StorageClass
を更新する必要があります。
バンドルされている
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 ファイルのパスに置き換えます。ファイルに変更を加える必要があるため、万一の場合に備えて
storage-class.yaml
のコピーを作成します。cp storage-class.yaml storage-class.yaml-backup.yaml
クラスタからデフォルトの
StorageClass
を削除します。kubectl delete storageclass standard-rwo \ --kubeconfig USER_CLUSTER_KUBECONFIG
storage-class.yaml
の構成を次のように更新します。次のフィールドを削除するか、コメントアウトします。
parameters.datastoreURL
resourceVersion
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
変更した
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
を更新します。
バンドルされている
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 のパスに置き換えます。ファイルに変更を加える必要があるため、万一の場合に備えて
storage-class-kubeception.yaml
のコピーを作成します。cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml
クラスタからデフォルトの
StorageClass
を削除します。kubectl delete storageclass USER_CLUSTER_NAME-csi \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
storage-class-kubeception.yaml
の構成を次のように更新します。次のフィールドを削除するか、コメントアウトします。
parameters.datastoreURL
resourceVersion
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
変更した
StorageClass
を管理クラスタに適用します。kubectl apply -f storage-class-kubeception.yaml \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG
管理クラスタを移行する
管理クラスタもストレージ ポリシー名で更新されていることを確認します。
管理クラスタの構成ファイルを次のように変更します。
vCenter.datastore
フィールドを削除するか、コメントアウトします。vCenter.storagePolicyName
フィールドにストレージ ポリシーの名前を設定します。
管理クラスタを更新します。
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG
次のように置き換えます。
ADMIN_CLUSTER_KUBECONFIG
: 管理クラスタの kubeconfig ファイルのパス。ADMIN_CLUSTER_CONFIG
: 管理クラスタの構成ファイルへのパス。
SPBM を使用したストレージの移行
データストアから SPBM への移行後、クラスタは SPBM を使用するようになります。ただし、この移行では、古いデータストアからストレージ ワークロード(マシン データディスクやコンテナ ボリュームなど)は移動されません。
ストレージ ワークロードを移動するには、ストレージ ポリシーベースの管理によるストレージの移行をご覧ください。