このガイドでは、GKE Volume Populator を使用して、動的プロビジョニング中に Cloud Storage バケットから Google Kubernetes Engine（GKE）の Hyperdisk ML ボリュームに大量のデータをプリロードする方法について説明します。詳細については、GKE Volume Populator についてをご覧ください。
このガイドは、ストレージの作成と割り当て、データ セキュリティとアクセスの管理を行うストレージ スペシャリストを対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
Hyperdisk ML を使用した GKE Volume Populator のノードプール管理
GKE Volume Populator によって作成されたデータ転送ジョブを正常に実行して Hyperdisk ML ボリュームにデータを入力するには、ノードプールのサイズ設定、プロビジョニング、スケーリングを効率的に行うことが重要です。コンピューティング クラスを使用して、これらの特定のデータ転送ジョブのノード要件（マシンタイプやサイズなど）を定義します。コンピューティング クラスを使用すると、データ転送プロセスの費用とパフォーマンスを制御できます。詳細については、カスタム コンピューティング クラスのメリットをご覧ください。
データ転送ジョブに最適なクラスタを選択するには、Hyperdisk ML でコンピューティング クラスがさまざまなクラスタタイプと連携する方法を理解します。
目標
このガイドでは、次のタスクを行います。
- GKE クラスタ環境を構成して、GKE Volume Populator を使用したデータ転送をサポートします。これには、クラスタの作成、コンピューティング クラスの定義、権限の設定が含まれます。
GCPDataSourceカスタム リソースを作成して、ソース Cloud Storage バケットを指定します。- Hyperdisk ML の
StorageClassを定義します。 GCPDataSourceを参照するPersistentVolumeClaimを作成して、Hyperdisk ML ボリュームへのデータ入力をトリガーします。- データ転送を確認する。
- Pod で入力されたボリュームを使用します。
- リソースをクリーンアップします。
始める前に
次のタスクが完了していることを確認します。
GKE API と Cloud Storage API を有効にします。
Google Cloud プロジェクトに対して課金が有効になっていることを確認します。
Google Cloud CLI コマンドライン ツールをダウンロードしてインストールするか、Cloud Shell を使用して
gcloud CLIコマンドとkubectlコマンドを実行します。Cloud Shell は、 Google Cloudでホストされているリソースを管理するためのシェル環境です。gcloud と kubectl コマンドライン ツールがプリインストールされています。Cloud Storage バケットを作成するか、既存のバケットを使用します。このガイドでは、モデルのトレーニング データが入力された Cloud Storage バケットがすでに存在することを前提としています。
ドライバが明示的に無効になっている可能性がある既存の Standard クラスタで、Compute Engine Persistent Disk CSI ドライバを有効にします。新しい Autopilot クラスタと Standard クラスタでは、GKE はデフォルトでドライバを有効にします。作成する宛先 Hyperdisk ML ストレージは、Compute Engine Persistent Disk の CSI ドライバで管理する必要があります。
クラスタで Workload Identity Federation for GKE を有効にします。これにより、GKE Volume Populator で使用される Kubernetes サービス アカウントがソースの Cloud Storage バケットにアクセスできるようになります。詳細については、必要な権限を設定するをご覧ください。
要件
GKE Volume Populator を使用してデータを転送するには、次の要件を満たしている必要があります。
- GKE クラスタでバージョン
1.33.2-gke.4780000以降を実行している必要があります。 GCPDataSourceカスタム リソースは、GKE ワークロードと同じ Namespace に存在している必要があります。異なる Namespace にまたがるデータソースはサポートされていません。- コンピューティング クラスを作成するときに、サポートされている VM を選択します。選択したマシンタイプに十分な割り当てがあることを確認します。
gcs-to-hdml-compute-classコンピューティング クラス名は転送ジョブ用に事前定義されています。コンピューティング クラスを作成するときに、この名前を正確に指定する必要があります。
費用
GKE Volume Populator の使用に直接費用はかかりませんが、ストレージとデータ転送には課金が発生します。関連する間接費には、次のものがあります。
- GKE で使用される Compute Engine インスタンス: データ転送ジョブの実行に使用されるノードの費用。ノードの管理とコストの影響は、クラスタタイプによって異なります。詳細については、GKE クラスタを作成するで、それぞれのクラスタタイプをご覧ください。
- 転送ジョブのノードサイズ: 最適な転送パフォーマンスを実現するため、転送ジョブはデフォルトで 24 個の vCPU を持つノードをスケールアップします。これはすべてのクラスタタイプに適用されます。特定の費用やパフォーマンスの最適化に合わせてノードのサイズとタイプを調整する場合は、コンピューティング クラスの作成時に調整できます。
- Cloud Storage バケットで使用されるストレージ: 詳細については、Cloud Storage の料金をご覧ください。
- Hyperdisk ML ボリュームの費用: 作成した Hyperdisk ML ボリュームのストレージ容量とパフォーマンス（IOPS/スループット）が含まれます。詳細については、Hyperdisk の料金をご覧ください。
環境を準備する
このセクションでは、適切なハードウェアを使用して GKE クラスタ インフラストラクチャを作成し、Cloud Storage のデータにアクセスするために必要な権限を設定します。
Hyperdisk ML で GKE Volume Populator を使用するクラスタを作成する前に、コンピューティング クラスがさまざまなタイプのクラスタにどのように適用されるか、ノード管理の責任者が GKE かユーザーかを確認してください。
Hyperdisk ML のさまざまなクラスタタイプでコンピューティング クラスがどのように機能するか
GKE Volume Populator は、カスタム コンピューティング クラスを使用して、データ転送ジョブに使用するノードのタイプを決定します。次の表に、クラスタ構成に応じたコンピューティング クラスの動作を示します。
| 検討対象 | GKE Autopilot、およびノードの自動プロビジョニングが有効になっている GKE Standard | GKE Standard（ノードの自動プロビジョニングなし） |
|---|---|---|
| コンピューティング クラスの設定 | nodePoolAutoCreation 有効 |
nodePoolAutoCreation が無効になりました |
| ノード管理 | GKE はノードを自動的に作成して管理します。 | ノードを手動で作成して管理します。 |
| ノードのスケーリング | 自動 | 手動 |
| ノードのラベル付け | 該当なし | ノードに cloud.google.com/compute-class=gcs-to-hdml-compute-class というラベルを付ける必要があります。 |
| 詳細 | ノードの自動プロビジョニングとコンピューティング クラス | 手動で作成したノードプールを構成する |
GKE は、PersistentVolumeClaim の PersistentVolume をプロビジョニングした後、データ転送ジョブを開始します。Hyperdisk ML ボリュームにデータを入力するには、この PersistentVolumeClaim が GCPDataSource を参照する必要があります。この GCPDataSource は、Cloud Storage のソースデータを定義します。
GKE クラスタを作成する
データ転送パイプラインは、GKE バージョン 1.33.2-gke.4780000 以降の Standard クラスタまたは Autopilot クラスタを使用してデプロイできます。各クラスタ タイプには、それぞれに利点があり、料金モデルも異なります。
- クラスタの管理、費用対効果、自動スケーリングを容易にするには、Autopilot を選択します。
- ノードのプロビジョニングをより詳細に制御して自動スケーリングを行う必要がある場合は、ノード自動プロビジョニングが有効になっている Standard を選択します。
- ノードのプロビジョニング、スケーリング、メンテナンスのすべての側面を管理する必要がある場合は、ノード自動プロビジョニングを有効にせずに Standard を選択します。
Autopilot
GKE Autopilot クラスタでは、GKE がデータ転送ジョブに必要なノードの作成と削除を自動的に処理します。転送ジョブが完了すると、ノードリソースは自動的にスケールダウンされます。転送 Pod や、Pod が実行されたノードを手動で削除する必要はありません。
新しい Autopilot クラスタを作成するには、次のコマンドを実行します。
gcloud container clusters create-auto CLUSTER_NAME \ --location=LOCATION \ --cluster-version=CLUSTER_VERSION
次のように置き換えます。
CLUSTER_NAME: 作成するクラスタの名前。LOCATION: クラスタのコンピューティング リージョン。例:us-central1CLUSTER_VERSION: クラスタの GKE バージョン。このガイドでは1.33.2-gke.4780000を使用します。
Standard（ノード自動プロビジョニングあり）
ノード自動プロビジョニングが有効になっている GKE Standard クラスタでは、GKE はデータ転送ジョブに必要なノードの作成と削除を自動的に処理します。転送ジョブが完了すると、ノードリソースは自動的にスケールダウンされます。転送 Pod や、Pod が実行されたノードを手動で削除する必要はありません。
ノードの自動プロビジョニングを有効にして新しい Standard クラスタを作成するには、次のコマンドを実行します。
gcloud container clusters create CLUSTER_NAME \ --cluster-version=CLUSTER_VERSION \ --location=LOCATION \ --project=PROJECT_ID \ --workload-pool=PROJECT_ID.svc.id.goog \ --enable-autoprovisioning \ --min-cpu MINIMUM_CPU \ --min-memory MINIMUM_MEMORY \ --max-cpu MAXIMUM_CPU \ --max-memory MAXIMUM_MEMORY \ --autoprovisioning-scopes=https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring,https://www.googleapis.com/auth/devstorage.read_only
次のように置き換えます。
CLUSTER_NAME: ノード自動プロビジョニングが有効になっている状態で作成するクラスタの名前。CLUSTER_VERSION: クラスタの GKE バージョン。このガイドでは1.33.2-gke.4780000を使用します。LOCATION: クラスタのコンピューティング ゾーンまたはコンピューティング リージョン。たとえば、us-central1-aやus-central1です。PROJECT_ID: Google Cloud プロジェクト ID。MINIMUM_CPU: 自動プロビジョニングの対象とする vCPU の最小数。たとえば、10です。MINIMUM_MEMORY: 自動プロビジョニングの対象とする最小メモリ容量（GiB）。たとえば、200です。MAXIMUM_CPU: 自動プロビジョニングの対象とする vCPU の最大数。たとえば、100です。この上限は、手動で作成した既存のすべてのノードプールにわたる CPU リソースと、GKE によって自動的に作成される可能性のあるすべてのノードプールにわたる CPU リソースの合計です。MAXIMUM_MEMORY: 自動プロビジョニングの対象とするメモリの最大量。たとえば、1000です。この上限は、手動で作成した既存のすべてのノードプールにわたるメモリリソースと、GKE によって自動的に作成される可能性のあるすべてのノードプールにわたるメモリリソースの合計です。
Standard（ノード自動プロビジョニングなし）
ノードの自動プロビジョニングが有効になっていない Standard クラスタで GKE Volume Populator を使用するには、既存のノードプールを使用するか、専用の転送ノードプールを作成します。ノードには、転送ジョブを実行する容量と compute-class と一致するラベルが必要です。
クラスタとノードプールを作成するときに、gcs-to-hdml-compute-class コンピューティング クラスをノードラベルとして指定します。コンピューティング クラス名 gcs-to-hdml-compute-class は転送ジョブ用に事前定義されているため、正確に指定する必要があります。
ノード自動プロビジョニングなしで新しい Standard クラスタを作成し、そのクラスタ内に新しいノードプールを作成するには、次のコマンドを実行します。
gcloud container clusters create CLUSTER_NAME \ --cluster-version=CLUSTER_VERSION \ --location=LOCATION \ --num-nodes=1 \ --project=PROJECT_ID \ --workload-pool=PROJECT_ID.svc.id.goog gcloud container node-pools create NODE_POOL_NAME\ --cluster=CLUSTER_NAME \ --location=LOCATION \ --num-nodes=1 \ --machine-type=c3-standard-44 \ --node-labels="cloud.google.com/compute-class=gcs-to-hdml-compute-class" \ --node-taints="cloud.google.com/compute-class=gcs-to-hdml-compute-class:NoSchedule"
次のように置き換えます。
CLUSTER_NAME: ノード自動プロビジョニングを有効にせずに作成するクラスタの名前。CLUSTER_VERSION: クラスタの GKE バージョン。このガイドでは1.33.2-gke.4780000を使用します。LOCATION: クラスタのコンピューティング リージョン。たとえば、us-central1-aやus-central1です。PROJECT_ID: 実際の Google Cloud プロジェクト ID。NODE_POOL_NAME: 新しいクラスタに作成するノードプールの名前。このノードプールは、GKE Volume Populator が一時的なデータ転送ジョブをデプロイするために使用します。
不要な費用が発生しないように、データ転送が完了したら gcloud container node-pools delete コマンドを実行して、手動で作成した転送ノードプールを削除します。
コンピューティング クラスを作成する
クラスタ内のノードとして使用できる VM のタイプを指定して優先順位を設定するコンピューティング クラスを作成する手順は次のとおりです。
- 次のマニフェストを
computeclass.yamlとして保存します。ノードの自動プロビジョニングあり
Autopilot クラスタと、ノード自動プロビジョニングが有効になっている Standard クラスタの場合は、次のように
nodePoolAutoCreationセクションを使用してコンピューティング クラスを定義します。ノードの自動プロビジョニングが有効になっている場合、GKE はgcs-to-hdml-compute-classコンピューティング クラスのラベルが付いた新しいノードプールを自動的に作成します。apiVersion: cloud.google.com/v1 kind: ComputeClass metadata: name: gcs-to-hdml-compute-class spec: priorities: - machineFamily: c3 - machineFamily: c3d nodePoolAutoCreation: enabled: true whenUnsatisfiable: DoNotScaleUp
ノードの自動プロビジョニングなし
ノード自動プロビジョニングが有効になっていない Standard クラスタの場合は、次のように
nodePoolAutoCreationセクションなしでコンピューティング クラスを定義します。gcs-to-hdml-compute-classコンピューティング クラスラベルを使用して、ノードプールがすでに作成されていることを確認します。apiVersion: cloud.google.com/v1 kind: ComputeClass metadata: name: gcs-to-hdml-compute-class spec: priorities: - machineFamily: c3 - machineFamily: c3d whenUnsatisfiable: DoNotScaleUp
データ転送のニーズに合わせて、互換性のある
machineFamilyを指定できます。適切なマシンタイプの選択の詳細については、Hyperdisk ML のマシンシリーズのサポートをご覧ください。 - コンピューティング クラスを作成するには、マニフェストを適用します。
kubectl apply -f computeclass.yaml
必要な権限を設定する
Cloud Storage バケットからデータを転送するには、Workload Identity Federation for GKE に必要な権限を設定します。適切な権限があれば、GKE Volume Populator によって作成された転送ジョブは Cloud Storage バケットにアクセスできます。このガイドでは、転送するモデル トレーニング データが入力された Cloud Storage バケットがすでに存在することを前提としています。
Kubernetes Namespace を作成します。
kubectl create namespace NAMESPACENAMESPACEは、ワークロードを実行する Namespace に置き換えます。既存の Namespace を使用している場合は、この手順をスキップします。
Kubernetes サービス アカウントを作成します。
kubectl create serviceaccount KSA_NAME \ --namespace=NAMESPACE次のように置き換えます。
KSA_NAME:GCPDataSourceリソースで指定する Kubernetes サービス アカウントの名前。GKE Volume Populator によって作成された転送ジョブは、このサービス アカウントを使用して Google Cloud API への認証を行います。NAMESPACE: 前の手順で作成した Kubernetes Namespace。
Cloud Storage バケットにアクセスできるように、IAM サービス アカウントに適切なロールを付与します。
gcloud storage buckets \ add-iam-policy-binding gs://GCS_BUCKET \ --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \ --role "ROLE"次のように置き換えます。
GCS_BUCKET: Cloud Storage バケット名。PROJECT_NUMBER: クラスタを作成した Google Cloud プロジェクトの数値識別子。プロジェクト番号を確認するには、プロジェクトの識別をご覧ください。PROJECT_ID: 実際の Google Cloud プロジェクト ID。NAMESPACE: ワークロードが実行される、前に作成した Namespace。KSA_NAME:GCPDataSourceリソースで指定した Kubernetes サービス アカウントの名前。GKE Volume Populator によって作成された転送ジョブは、このサービス アカウントを使用して Google Cloud API への認証を行います。ROLE: サービス アカウントに付与する IAM ロール。このガイドでは、バケットからの読み取りを許可するためにroles/storage.objectViewerロールを付与します。
PROJECT_NUMBER、PROJECT_ID、NAMESPACE、KSA_NAMEは、プロジェクトの Workload Identity Federation for GKE プリンシパル ID の構築に使用されます。
プリロードされたデータを含む Hyperdisk ML ボリュームを作成する
Hyperdisk ML ボリュームの作成に必要な GKE インフラストラクチャと構成を設定し、GKE Volume Populator を使用して自動データ転送プロセスをトリガーして管理するには、次の操作を行います。
GCPDataSourceカスタム リソースを作成して、データのソースを定義します。- 使用する永続ストレージのタイプ（Hyperdisk ML ボリューム）を定義する StorageClass を作成します。
- PersistentVolumeClaim を作成して、ストレージの動的プロビジョニングを有効にし、新しくプロビジョニングされた Hyperdisk ML ボリュームへのアクセスを有効にします。
- （省略可）データ転送の進行状況を確認する。
- Hyperdisk ML ボリュームを使用する Pod を作成してデプロイします。
GCPDataSource カスタム リソースを作成する
GKE に GCPDataSource カスタム リソースを作成して、ソース Cloud Storage バケットのロケーションと、そのバケットにアクセスするために必要な権限を持つサービス アカウントを指定します。このカスタム リソース定義（CRD）は、GKE Volume Populator に固有のものです。
次のマニフェストを
gcpdatasource.yamlとして保存します。apiVersion: datalayer.gke.io/v1 kind: GCPDataSource metadata: name: GCP_DATA_SOURCE namespace: NAMESPACE spec: cloudStorage: serviceAccountName: KSA_NAME uri: gs://GCS_BUCKET/次の値を置き換えます。
- GCP_DATA_SOURCE: Cloud Storage バケットへの参照を保持する
GCPDataSourceCRD の名前。詳細については、GCPDataSourceCRD リファレンスをご覧ください。 - NAMESPACE: ワークロードが実行される Namespace と同じ Namespace。
GCPDataSourceカスタム リソースは、この Namespace に作成されます。 - KSA_NAME:
GCPDataSourceリソースで指定した Kubernetes サービス アカウントの名前。GKE Volume Populator によって作成された転送ジョブは、このサービス アカウントを使用して Google Cloud API への認証を行います。cloudStorage.serviceAccountNameの値は、必要な権限を設定するセクションで Workload Identity Federation for GKE 用に設定した Kubernetes サービス アカウントです。 - GCS_BUCKET: Cloud Storage バケット名。
uriフィールドには、ソースデータを指定します。- バケット全体をコピーするには、
gs://GCS_BUCKET/を使用します。 - バケット内の特定のフォルダからデータをコピーするには、
gs://GCS_BUCKET/PATH_INSIDE_BUCKET/形式を使用します。たとえば、my-project-llm-modelsバケット内のgemma/v1.0/weights/フォルダからデータをコピーする場合、URI はgs://my-project-llm-models/gemma/v1.0/weights/になります。パスの末尾がスラッシュで終わっていることを確認します。これはフォルダを示します。
- バケット全体をコピーするには、
- GCP_DATA_SOURCE: Cloud Storage バケットへの参照を保持する
GCPDataSourceリソースを作成するには、マニフェストを適用します。kubectl apply -f gcpdatasource.yaml
Hyperdisk ML StorageClass を作成する
pd.csi.storage.gke.io プロビジョナーを使用して、選択したゾーンに Hyperdisk ML ボリュームをプロビジョニングする StorageClass を作成します。データのコピーに複数のゾーンからアクセスできるようにするには、マルチゾーン StorageClass を作成します。マルチゾーン StorageClass の例を次に示します。
次のマニフェストを
hdml-class.yamlとして保存します。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: hyperdisk-ml-single-zone parameters: type: hyperdisk-ml provisioned-throughput-on-create: "2400Mi" provisioner: pd.csi.storage.gke.io allowVolumeExpansion: false reclaimPolicy: Delete volumeBindingMode: Immediate allowedTopologies: - matchLabelExpressions: - key: topology.gke.io/zone values: - ZONEZONEは、Hyperdisk ML ボリュームを作成するターゲット ゾーンに置き換えます。- ノードの自動プロビジョニングを使用しない GKE Standard クラスタの場合、
ZONEの値はノードを作成したロケーションである必要があります。 - ノードの自動プロビジョニングを使用する GKE Autopilot クラスタまたは Standard クラスタの場合、
ZONEの値は、クラスタをスケールアップして必要に応じて新しいノードを作成できるロケーションにする必要があります。
- ノードの自動プロビジョニングを使用しない GKE Standard クラスタの場合、
（省略可）クラスタのノードのロケーションを一覧表示するには、次のコマンドを実行します。
gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(locations)"次のように置き換えます。
CLUSTER_NAME: クラスタの名前。LOCATION: クラスタのコンピューティング ゾーンまたはコンピューティング リージョン。たとえば、us-central1-aやus-central1です。
StorageClass を作成するには、マニフェストを適用します。
kubectl apply -f hdml-class.yaml
PersistentVolumeClaim を作成してボリュームにアクセスする
次のマニフェストは、前に作成した StorageClass を参照する ReadOnlyMany アクセスモードで PersistentVolumeClaim を作成する方法の例を示しています。
次のマニフェストを
volume-populator-pvc.yamlとして保存します。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: PVC_NAME namespace: NAMESPACE spec: accessModes: - ReadOnlyMany storageClassName: hyperdisk-ml-single-zone resources: requests: storage: DISK_SIZE dataSourceRef: apiGroup: datalayer.gke.io kind: GCPDataSource name: GCP_DATA_SOURCE次の値を置き換えます。
PVC_NAME: データを転送する PersistentVolumeClaim の名前。NAMESPACE: ワークロードが実行される Namespace。DISK_SIZE: データの入力用に作成されるディスクのサイズ（ギガバイト単位）。データを正常に読み込むには、リクエストされたディスクサイズが、Cloud Storage バケットにあるモデルのデータのサイズよりも大きいことを確認してください。Hyperdisk ML ボリュームでサポートされている範囲に準拠するには、DISK_SIZEの値が 4 Gi より大きくなければなりません。詳細については、Hyperdisk ボリュームのサイズ上限をご覧ください。GCP_DATA_SOURCE: Cloud Storage バケットへの参照を保持するGCPDataSourceCRD の名前。
PVC に省略可能なアノテーションを追加することで、データ転送をカスタマイズできます。これらのアノテーションは、データを Hyperdisk ML ボリュームにコピーする基盤となる転送ジョブの動作に影響します。
volume-populator.datalayer.gke.io/cpu-request: このアノテーションを使用して、転送Jobに別の CPU リソース リクエストを指定します。別の CPU リソース リクエストを指定しない場合、PVC は転送パフォーマンスを最適化するためにデフォルトで 24 個の vCPU をリクエストします。volume-populator.datalayer.gke.io/transfer-path: このアノテーションを使用して、GCPDataSourceリソースからコピーされたデータを保存する新しいボリューム内の宛先パスを指定します。別のパスを指定しない場合、データは Hyperdisk ML ボリューム内のルートパスにコピーされます。
PVC を作成するには、マニフェストを適用します。
kubectl apply -f volume-populator-pvc.yaml
留意点:
- StorageClass の
volumeBindingModeフィールドをimmediateに設定すると、PVC のデプロイ時にデータ転送がすぐにトリガーされます。 - StorageClass の
volumeBindingModeフィールドをWaitForFirstConsumerに設定すると、PVC をリクエストする Pod をデプロイし、その Pod がノードに正常にスケジュールされた後にのみ、データ転送がトリガーされます。Pod はスケジュールできますが、コンテナはデータ転送が完了してボリュームが使用可能になるまで起動を待機します。
データ移行の進行状況を確認するには、データ転送の進行状況を確認するをご覧ください。リソースのプロビジョニングまたはデータ転送中にエラーが発生した場合は、GKE Volume Populator のデータ転送に関する問題のトラブルシューティングをご覧ください。
（省略可）データ転送の進行状況を確認する
このセクションでは、Cloud Storage バケットから Hyperdisk ML ボリュームへのデータ転送の進行状況と成功を追跡する方法について説明します。
PersistentVolumeClaim のステータスを確認するには、次のコマンドを実行します。PersistentVolumeClaim のバインド オペレーションの完了に時間がかかりすぎる場合も、このコマンドを実行できます。
kubectl describe pvc PVC_NAME -n NAMESPACE次のように置き換えます。
PVC_NAME: PersistentVolumeClaim を作成して Volume にアクセスするセクションで作成した PVC の名前。NAMESPACE: このガイド全体で使用される名前空間。必要な権限を設定するセクションで作成したものです。
出力で、PersistentVolumeClaim イベントを確認して、データ転送の進行状況をモニタリングします。GKE は、イベントを 1 分に 1 回程度ログに記録します。出力は次のようになります。
Name: vp-pvc Namespace: default StorageClass: hyperdisk-ml-single-zone Status: Bound Volume: pvc-f7ae2ee2-106d-4b87-b458-481a3ff82b62 Labels: <none> Annotations: pv.kubernetes.io/bind-completed: yes pv.kubernetes.io/bound-by-controller: yes volume.beta.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io volume.kubernetes.io/storage-provisioner: pd.csi.storage.gke.io Finalizers: [kubernetes.io/pvc-protection] Capacity: 200Gi Access Modes: ROX VolumeMode: Filesystem DataSource: APIGroup: datalayer.gke.io Kind: GCPDataSource Name: vp-gds Used By: verify-data-665cfd4dbf-mwc7t verify-data-665cfd4dbf-n7xw9 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ProvisioningFailed 9m8s persistentvolume-controller Error saving claim: Operation cannot be fulfilled on persistentvolumeclaims "vp-pvc": the object has been modified; please apply your changes to the latest version and try again Normal Provisioning 9m5s pd.csi.storage.gke.io_gke-f110123a1cbd44cdaa7a-921b-b1f4-vm_1a100bd9-5231-4f20-8e65-1f8e995a03c0 External provisioner is provisioning volume for claim "default/vp-pvc" Normal Provisioning 9m5s external-provisioner Assuming an external populator will provision the volume Normal PopulateOperationStartSuccess 8m58s gkevolumepopulator-populator populateFn: Populate operation started for zone us-central1-c Normal TransferInProgress 8m58s (x2 over 8m58s) gkevolumepopulator-populator populateCompleteFn: For PVC vp-pvc in namespace default, transfer job with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f in zone us-central1-c waiting for pod to get created Normal TransferInProgress 6m10s (x14 over 8m57s) gkevolumepopulator-populator populateCompleteFn: For PVC vp-pvc in namespace default, transfer job in zone us-central1-c with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f is still active with pod status as - Phase: Pending Normal ExternalProvisioning 3m35s (x24 over 9m5s) persistentvolume-controller Waiting for a volume to be created either by the external provisioner 'pd.csi.storage.gke.io' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered. Normal TransferJobCompleted 3m24s (x2 over 3m26s) gkevolumepopulator-populator populateCompleteFn: For PVC vp-pvc in namespace default, job with request ID populator-job-2304531e-4937-4534-a1a4-3eb11e5cb39f for zone us-central1-c completed successfully Normal TransferJobCompleted 3m24s (x2 over 3m26s) gkevolumepopulator-populator populateCompleteFn: For PVC vp-pvc in namespace default, transfer job for all zones have completed successfully Normal PopulateOperationFinished 3m24s (x2 over 3m26s) gkevolumepopulator-populator Populate operation finished Normal PopulatorFinished 3m19s (x3 over 3m20s) gkevolumepopulator-populator Populator finished
データサイズによっては、入力オペレーションの開始に数分かかることがあります。数分経ってもデータ転送の進行状況が表示されない場合は、GKE Volume Populator のデータ転送に関する問題のトラブルシューティングをご覧ください。
マルチゾーン Hyperdisk ML ボリュームのデータ転送の場合、データが StorageClass で指定されたすべてのゾーンに正常に転送された場合にのみ、ジョブは完了とマークされます。1 つ以上のゾーンで転送ジョブが失敗した場合、PVC が存在する限り、GKE Volume Populator はデータの転送を無期限に再試行します。
ボリュームを使用する Pod を作成してデプロイする
データが入力された PVC の内容を確認する Pod を作成するには:
次のマニフェストを
verify-data.yamlとして保存します。apiVersion: v1 kind: Pod metadata: name: verify-data namespace: NAMESPACE spec: nodeSelector: cloud.google.com/compute-class: gcs-to-hdml-compute-class containers: - name: verify-data image: busybox command: - sleep - infinity volumeMounts: - mountPath: /models name: mypvc volumes: - name: mypvc persistentVolumeClaim: claimName: PVC_NAME次のように置き換えます。
NAMESPACE: PVC が配置され、verify-dataPod を作成する Namespace。PVC_NAME: PersistentVolumeClaim を作成して Volume にアクセスするセクションでデータ入力用に作成した PVC の名前。
次のコマンドを使用して Pod を作成します。
kubectl create -f verify-data.yamlファイルを一覧表示するには、次のコマンドを実行します。
kubectl exec -it verify-data -- /bin/sh # cd /models && ls
コマンドが成功すると、Cloud Storage バケット内の /models ディレクトリにデータが入力されます。
クリーンアップ
不要な費用を回避し、構成ミスや孤立したリソースを削除するには、PersistentVolumeClaim を正常に削除する手順に沿って操作します。
動的プロビジョニング中に PersistentVolumeClaim を削除する
動的プロビジョニング中にデータが転送されている間に PersistentVolumeClaim を削除する必要がある場合は、次の手順で正常な削除を行います。正常な削除が完了するまでに時間がかかることがあります。
削除プロセス中に、次の関連する変数を置き換えます。
POD_NAME: ボリュームを消費する Pod を作成してデプロイするセクションで作成した Pod の名前。NAMESPACE: PVC が配置されている Namespace。PVC_NAME: PersistentVolumeClaim を作成して Volume にアクセスするセクションで作成した PVC の名前。GCP_DATA_SOURCE:GCPDataSourceカスタム リソースを作成するで作成したGCPDataSourceカスタム リソースの名前。
ワークロード Pod を削除します。
kubectl delete pod POD_NAME -n NAMESPACE一時的な PersistentVolumeClaim の名前を確認します。
# Store the relevant environment variables export PVC_NAME=PVC_NAME export NAMESPACE=NAMESPACE# Check the status export PVC_UID=$(kubectl get pvc ${PVC_NAME} -n ${NAMESPACE} -o jsonpath='{.metadata.uid}') export TEMP_PVC=prime-${PVC_UID} echo ${TEMP_PVC}Namespace に作成された PVC を削除します。
kubectl delete pvc PVC_NAME -n NAMESPACEPVC が
Terminating状態のままになることがあります。NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE vp-pvc Terminating hyperdisk-ml <unset> 7m23sその場合は、ファイナライザーを削除して PVC を手動でクリーンアップします。
kubectl patch pvc PVC_NAME -n NAMESPACE -p '{"metadata":{"finalizers":null}}'PVC が削除された後にのみ
GCPDataSourceリソースを削除します。最初にGCPDataSourceリソースを削除すると、PVC の削除が停止します。kubectl delete gcpdatasource GCP_DATA_SOURCE -n NAMESPACE一時リソースが削除されていることを確認します。
次のステップ
- GKE Volume Populator について学習する。
- データ転送に関する問題については、GKE Volume Populator のデータ転送に関する問題をトラブルシューティングするをご覧ください。
- Hyperdisk ML の高度なワークロードの例については、Hyperdisk ML で AI/ML データの読み込みを高速化するをご覧ください。