このガイドでは、GKE Volume Populator を使用して、動的プロビジョニング中に Cloud Storage バケットから Google Kubernetes Engine（GKE）の Hyperdisk ML ボリュームに大量のデータをプリロードする方法について説明します。詳細については、GKE Volume Populator についてをご覧ください。
このガイドは、ストレージの作成と割り当てを行い、データ セキュリティとアクセスを管理するストレージ スペシャリストを対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスク例の詳細については、GKE ユーザーの一般的なロールとタスクをご覧ください。
Hyperdisk ML を使用した GKE Volume Populator のノードプール管理
GKE Volume Populator によって作成されたデータ転送 Job を正常に実行して Hyperdisk ML ボリュームにデータを入力するには、ノードプールのサイズ設定、プロビジョニング、スケーリングを効率的に行うことが重要です。これらの特定のデータ転送 Job のノード要件（マシンタイプやサイズなど）を定義するには、ComputeClass を使用します。ComputeClass を使用すると、データ転送プロセスの費用とパフォーマンスを制御できます。詳細については、カスタム ComputeClass のメリットをご覧ください。
データ転送 Job に最適なクラスタを選択するには、Hyperdisk ML のクラスタタイプごとの ComputeClass の動作を理解します。
目標
このガイドでは、次のタスクを行います。
- GKE Volume Populator を使用したデータ転送をサポートするように GKE クラスタ環境を構成します（クラスタの作成、ComputeClass の定義、権限の設定など）。
GCPDataSourceカスタム リソースを作成して、ソース Cloud Storage バケットを指定します。- Hyperdisk ML の
StorageClassを定義します。 GCPDataSourceを参照して Hyperdisk ML ボリュームへのデータ入力をトリガーするPersistentVolumeClaimを作成します。- データ転送を確認します。
- 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 にまたがるデータソースはサポートされていません。- ComputeClass を作成するときに、サポートされている VM を選択します。選択したマシンタイプに十分な割り当てがあることを確認します。
- 転送 Job の
gcs-to-hdml-compute-classComputeClass の名前は事前定義されています。ComputeClass を作成するときに、この名前を正確に指定する必要があります。
費用
GKE Volume Populator の使用に直接的な費用はかかりませんが、ストレージとデータ転送には料金が発生します。関連する間接的な費用には、次のものが含まれます。
- GKE で使用される Compute Engine インスタンス: データ転送 Job の実行に使用されるノードの費用。ノード管理と費用への影響は、クラスタタイプによって異なります。詳細については、GKE クラスタを作成するの各クラスタタイプをご覧ください。
- 転送 Job のノードサイズ: 最適な転送パフォーマンスを実現するために、転送 Job はノードをデフォルトで 24 個の vCPU にスケールアップします。これはすべてのクラスタタイプに適用されます。特定の費用やパフォーマンスの最適化のためにノードのサイズとタイプを調整する場合は、ComputeClass を作成する際に調整できます。
- Cloud Storage バケットで使用されるストレージ: 詳細については、Cloud Storage の料金をご覧ください。
- Hyperdisk ML ボリュームの費用: 作成した Hyperdisk ML ボリュームのストレージ容量とパフォーマンス（IOPS / スループット）が含まれます。詳細については、Hyperdisk の料金をご覧ください。
環境を準備する
このセクションでは、適切なハードウェアを使用して GKE クラスタ インフラストラクチャを作成し、Cloud Storage のデータにアクセスするために必要な権限を設定します。
Hyperdisk ML で GKE Volume Populator を使用するクラスタを作成する前に、ComputeClass がさまざまなクラスタタイプにどのように適用されるか、およびノード管理を誰が担当するのか（GKE またはお客様）を確認してください。
Hyperdisk ML のクラスタタイプごとの ComputeClass の動作
GKE Volume Populator は、カスタム ComputeClass を使用して、データ転送 Job に使用するノードのタイプを決定します。次の表に、クラスタ構成に応じた ComputeClass の動作を示します。
| 検討対象 | GKE Autopilot、ノード自動プロビジョニングありの GKE Standard | ノード自動プロビジョニングなしの GKE Standard |
|---|---|---|
| ComputeClass の設定 | nodePoolAutoCreation が有効 |
nodePoolAutoCreation が無効 |
| ノード管理 | GKE がノードを自動的に作成して管理する | ノードを手動で作成して管理する |
| ノードのスケーリング | 自動 | 手動 |
| ノードのラベル付け | 該当なし | ノードに cloud.google.com/compute-class=gcs-to-hdml-compute-class というラベルを付ける必要がある |
| 詳細情報 | ノード自動プロビジョニングと ComputeClass | 手動で作成したノードプールを構成する |
GKE は、PersistentVolumeClaim の PersistentVolume をプロビジョニングした後、データ転送 Job を開始します。Hyperdisk ML ボリュームにデータを入力するには、この PersistentVolumeClaim が、Cloud Storage のソースデータを定義する GCPDataSource を参照する必要があります。
GKE クラスタを作成する
データ転送パイプラインは、GKE バージョン 1.33.2-gke.4780000 以降の Standard クラスタまたは Autopilot クラスタを使用してデプロイできます。各クラスタタイプには、それぞれに利点があり、料金モデルも異なります。
- 容易なクラスタ管理、費用対効果、自動スケーリングを必要とする場合には、Autopilot を選択します。
- ノード プロビジョニングをより詳細に制御して自動スケーリングを行う必要がある場合は、ノード自動プロビジョニングが有効になっている Standard を選択します。
- 最大限の制御を必要とし、ノード プロビジョニング、スケーリング、メンテナンスのすべての側面を自分で管理できる場合は、ノード自動プロビジョニングが有効になっていない Standard を選択します。
Autopilot
GKE Autopilot クラスタでは、GKE がデータ転送 Job に必要なノードの作成と削除を自動的に処理します。転送 Job が完了すると、ノードリソースは自動的にスケールダウンされます。転送 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 がデータ転送 Job に必要なノードの作成と削除を自動的に処理します。転送 Job が完了すると、ノードリソースは自動的にスケールダウンされます。転送 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 を使用するには、既存のノードプールを使用するか、専用の転送ノードプールを作成します。ノードには、転送 Job を実行する容量と、compute-class と一致するラベルが必要です。
クラスタとノードプールを作成するときに、gcs-to-hdml-compute-class ComputeClass をノードラベルとして指定します。転送 Job の ComputeClass の名前 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-central1PROJECT_ID: 実際の Google Cloud プロジェクト ID。NODE_POOL_NAME: 新しいクラスタに作成するノードプールの名前。このノードプールは、GKE Volume Populator が一時的なデータ転送 Job をデプロイするために使用します。
不要な費用が発生しないように、データ転送が完了したら gcloud container node-pools delete コマンドを実行して、手動で作成した転送ノードプールを削除します。
ComputeClass を作成する
クラスタのノードとして使用できる VM のタイプを指定して優先する ComputeClass を作成する手順は次のとおりです。
- 次のマニフェストを
computeclass.yamlとして保存します。ノード自動プロビジョニングあり
Autopilot クラスタと、ノード自動プロビジョニングが有効になっている Standard クラスタの場合は、次のように
nodePoolAutoCreationセクションを含めて ComputeClass を定義します。ノード自動プロビジョニングが有効になっている場合、GKE はgcs-to-hdml-compute-classComputeClass ラベルの付いた新しいノードプールを自動的に作成します。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セクションを含めずに ComputeClass を定義します。gcs-to-hdml-compute-classComputeClass ラベルの付いたノードプールがすでに作成されていることを確認します。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 のマシンシリーズのサポートをご覧ください。 - ComputeClass を作成するには、マニフェストを適用します。
kubectl apply -f computeclass.yaml
必要な権限を設定する
Cloud Storage バケットからデータを転送するには、Workload Identity Federation for GKE に必要な権限を設定します。適切な権限を付与することで、GKE Volume Populator によって作成された転送 Job が 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 によって作成された転送 Job は、このサービス アカウントを使用して 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 プロジェクトの数値 ID。プロジェクト番号を確認するには、プロジェクトを確認するをご覧ください。PROJECT_ID: 実際の Google Cloud プロジェクト ID。NAMESPACE: ワークロードが実行される、先ほど作成した Namespace。KSA_NAME:GCPDataSourceリソースで指定した Kubernetes サービス アカウントの名前。GKE Volume Populator によって作成された転送 Job は、このサービス アカウントを使用して 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カスタム リソースを作成して、データソースを定義します。- StorageClass を作成して、使用する永続ストレージのタイプ（Hyperdisk ML ボリューム）を定義します。
- 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。
GCPDataSourceカスタム リソースは、この Namespace に作成されます。 - KSA_NAME:
GCPDataSourceリソースで指定した Kubernetes サービス アカウントの名前。GKE Volume Populator によって作成された転送 Job は、このサービス アカウントを使用して 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: データの入力用に作成されるディスクのサイズ（GB 単位）。データを正常に入力するには、リクエストされたディスクサイズが、Cloud Storage バケットにあるモデルのデータのサイズよりも大きいことを確認してください。Hyperdisk ML ボリュームでサポートされている範囲に準拠するには、DISK_SIZEの値が 4 Gi より大きくなければなりません。詳細については、Hyperdisk ボリュームのサイズ上限をご覧ください。GCP_DATA_SOURCE: Cloud Storage バケットへの参照を保持するGCPDataSourceCRD の名前。
PVC にアノテーション（省略可）を追加することで、データ転送をカスタマイズできます。これらのアノテーションは、データを Hyperdisk ML ボリュームにコピーする基盤となる転送 Job の動作に影響します。
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 を作成するセクションで作成した PVC の名前。NAMESPACE: 必要な権限を設定するセクションで作成した、このガイド全体で使用される 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 で指定されたすべてのゾーンにデータが正常に転送された場合にのみ Job が完了とマークされます。1 つ以上のゾーンで転送 Job が失敗した場合、GKE Volume Populator は PVC が存在する限り、データ転送を無期限に再試行します。
ボリュームを使用する 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 を作成するセクションでデータ入力用に作成した 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 を作成するセクションで作成した 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 データの読み込みを高速化するを確認する。