セカンダリブートディスクを使用してデータまたはコンテナイメージをプリロードする
コレクションでコンテンツを整理必要に応じて、コンテンツの保存と分類を行います。

Autopilot Standard

このページでは、Google Kubernetes Engine（GKE）でセカンダリブートディスクを使用して、新しいノードにデータまたはコンテナイメージをプリロードし、ワークロードの起動レイテンシを改善する方法について説明します。これにより、ワークロードではコールドスタートの高速化と、プロビジョニングされたリソースの全体的な使用率の向上が実現します。

このページを読む前に、 Google Cloud、Kubernetes、コンテナ、YAML、containerd ランタイム、Google Cloud CLI について理解しておいてください。

概要

Standard クラスタの GKE バージョン 1.28.3-gke.1067000 以降と Autopilot クラスタの GKE バージョン 1.30.1-gke.1329000 以降では、セカンダリブートディスクを使用してノードプールを構成できます。GKE には、ノードをプロビジョニングして、ML モデルやコンテナイメージなどのデータをプリロードするように指示できます。プリロードされたコンテナイメージやセカンダリディスクのデータを使用すると、ワークロードに次のようなメリットがあります。

大規模なコンテナイメージの pull やデータのダウンロード時のレイテンシの短縮
自動スケーリングの高速化
メンテナンスイベントやシステムエラーなどの中断からの迅速な復元

以降のセクションでは、GKE Autopilot クラスタと Standard クラスタでセカンダリブートディスクを構成する方法について説明します。

セカンダリブートディスクの仕組み

セカンダリブートディスクにプリロードされたコンテナイメージまたはデータを使用することで、ワークロードの起動を高速化できます。セカンダリブートディスクには次の特性があります。

セカンダリブートディスクは、分散ブロックストレージを基盤とする Persistent Disk です。
Persistent Disk は、事前に作成したディスクイメージからインスタンス化されます。
スケーラビリティ上の理由から、各ノードにはディスクイメージから独自の Persistent Disk インスタンスが作成されます。これらの Persistent Disk インスタンスは、ノードが削除されると削除されます。
ディスクイメージがゾーンですでに使用されている場合、同じディスクイメージから作成される後続のディスクの作成時間は短くなります。
セカンダリブートディスクのタイプは、ノードのブートディスクと同じです。
セカンダリブートディスクのサイズは、ディスクイメージのサイズによって決まります。

ノードプールにセカンダリブートディスクを追加しても、ノードのプロビジョニング時間は増加しません。GKE は、ノードのプロビジョニングプロセスと並行して、ディスクイメージからセカンダリブートディスクをプロビジョニングします。

ベストプラクティス:

プリロードされたコンテナイメージをサポートするため、GKE は、セカンダリブートディスクからコンテナイメージを読み取るプラグインを使用して containerd ランタイムを拡張します。コンテナイメージはベースレイヤで再利用されます。

大きなベースレイヤはセカンダリブートディスクにプリロードし、小さな上位レイヤをコンテナレジストリから pull できます。

始める前に

作業を始める前に、次のことを確認してください。

Google Kubernetes Engine API を有効にする。

Google Kubernetes Engine API の有効化

このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。
注: gcloud CLI がすでにインストールされている場合には、必ず compute/region と compute/zone のプロパティを設定してください。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。

Container File System API を有効にします。

Container File System API を有効にする

要件

セカンダリブートディスクの使用には、次の要件が適用されます。

クラスタが GKE Standard で、GKE バージョン 1.28.3-gke.1067000 または GKE Autopilot でバージョン 1.30.1-gke.1329000 を実行している。
ディスクイメージを変更するときは、新しいノードプールを作成する必要があります。既存のノードのディスクイメージの更新はサポートされていません。
セカンダリブートディスク機能を使用するようにイメージストリーミングを構成します。
containerd ノードイメージで Container-Optimized OS を使用します。Autopilot ノードはデフォルトでこのノードイメージを使用します。
ビルド時にデータが準備されたディスクイメージを準備するか、プリロードされたコンテナイメージを使用してディスクイメージを準備します。クラスタがディスクイメージにアクセスしてノードに読み込まれるようにします。

ベストプラクティス:
CI / CD パイプラインでディスクイメージを自動化します。

制限事項

セカンダリブートディスクには次の制限があります。

既存ノードのセカンダリブートディスクを更新することはできません。新しいディスクイメージを接続するには、新しいノードプールを作成します。
セカンダリブートディスクを使用して GKE Autopilot クラスタにデータをプリロードすることはできません。

料金

セカンダリブートディスクを使用してノードプールを作成すると、GKE はノードプール内の各ノードに Persistent Disk をアタッチします。Persistent Disk は、Compute Engine ディスクの料金に基づいて課金されます。

セカンダリブートディスクイメージを準備する

セカンダリブートディスクイメージを準備するときに、コンテナイメージをプリロードする場合は [イメージ] タブを選択し、データをプリロードする場合は [データ] タブを選択して、次の手順を完了します。

イメージ

GKE には、仮想マシン（VM）を作成してディスク上のコンテナイメージを pull し、そのディスクからディスクイメージを作成する gke-disk-image-builder というツールが用意されています。

複数のプリロードされたコンテナイメージを含むディスクイメージを作成するには、次の操作を行います。

gke-disk-image-builder の実行ログを保存する Cloud Storage バケットを作成します。
gke-disk-image-builder を使用してディスクイメージを作成します。

go run ./cli \
    --project-name=PROJECT_ID \
    --image-name=DISK_IMAGE_NAME \
    --zone=LOCATION \
    --gcs-path=gs://LOG_BUCKET_NAME \
    --disk-size-gb=10 \
    --container-image=docker.io/library/python:latest \
    --container-image=docker.io/library/nginx:latest

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

PROJECT_ID: Google Cloud プロジェクトの名前。
DISK_IMAGE_NAME: ディスクのイメージの名前。例: nginx-python-image
LOCATION: クラスタのロケーション。
LOG_BUCKET_NAME: 実行ログを保存する Cloud Storage バケットの名前。例: gke-secondary-disk-image-logs/

gke-disk-image-builder を使用してディスクイメージを作成すると、Google Cloud によってプロセスを完了するために複数のリソース（VM インスタンス、一時ディスク、永続ディスクなど）が作成されます。実行後、イメージビルダーは、作成したディスクイメージを除くすべてのリソースをクリーンアップします。

データ

次の手順で、データソースとしてカスタムディスクイメージを作成します。

セカンダリブートディスクを構成する

セカンダリブートディスクは、GKE Autopilot クラスタまたは GKE Standard クラスタで構成できます。

ベストプラクティス:

フルマネージドの Kubernetes エクスペリエンスを実現するには、Autopilot クラスタを使用します。ワークロードに最適な GKE の運用モードを選択するには、GKE の運用モードを選択するをご覧ください。

GKE Autopilot を使用する

このセクションでは、ディスクイメージの許可リストを作成し、既存の GKE Autopilot クラスタでディスクイメージを許可します。次に、セカンダリブートディスクを使用するように Pod ノードセレクタを変更します。

プロジェクトでディスクイメージを許可する

このセクションでは、GKE がGoogle Cloud プロジェクトのディスクイメージからセカンダリブートディスクを含むノードを作成できるように GCPResourceAllowlist を作成します。

次のマニフェストを allowlist-disk.yaml として保存します。

apiVersion: "node.gke.io/v1"
kind: GCPResourceAllowlist
metadata:
  name: gke-secondary-boot-disk-allowlist
spec:
  allowedResourcePatterns:
  - "projects/PROJECT_ID/global/images/.*"

PROJECT_ID は、ディスクイメージをホストするプロジェクト ID に置き換えます。

次のようにマニフェストを適用します。
```
kubectl apply -f allowlist-disk.yaml
```
GKE は、プロジェクト内のすべてのディスクイメージからセカンダリブートディスクを含むノードを作成します。

セカンダリブートディスクを使用するように Pod ノードセレクタを更新する

このセクションでは、GKE がセカンダリブートディスクを使用してノードを作成するように Pod 仕様を変更します。

Pod テンプレートに nodeSelector を追加します。
```
nodeSelector:
    cloud.google.com.node-restriction.kubernetes.io/gke-secondary-boot-disk-DISK_IMAGE_NAME: CONTAINER_IMAGE_CACHE.PROJECT_ID
```
次のように置き換えます。
- DISK_IMAGE_NAME: ディスクイメージの名前。
- PROJECT_ID: ディスクイメージをホストするプロジェクト ID。
kubectl apply コマンドを使用して、Pod テンプレートを使用して Kubernetes 仕様を適用します。
セカンダリブートディスクキャッシュが使用中であることを確認します。
```
kubectl get events --all-namespaces
```
出力は次のようになります。
```
75s         Normal      SecondaryDiskCachin
node/gke-pd-cache-demo-default-pool-75e78709-zjfm   Image
gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary disk cache
```
注: イベントの量が多い場合、Kubernetes によってイベントがスロットリングされる可能性があります。イベントが欠落しているからといって、セカンダリブートディスクが使用されなかったことを示すものではありません。次の手順では、信頼性の高い方法でセカンダリブートディスクが使用されたことを確認します。
セカンダリブートディスクキャッシュが使用中であることを確認する信頼性の高い方法は次のとおりです。

次のログ名を使用して、対象のノードのログをクエリします。
```
logName="projects/PROJECT_ID/logs/gcfs-snapshotter"
```
PROJECT_ID は、実際の Google Cloud プロジェクト ID に置き換えます。

Image gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary boot disk caching by 100.0%... のようなログは、セカンダリブートディスクキャッシュが使用されたことを示します。

イメージ pull のレイテンシを確認します。

kubectl describe pod POD_NAME

POD_NAME は、Pod の名前で置き換えます。

出力は次のようになります。

…
  Normal  Pulled     15m   kubelet            Successfully pulled image "docker.io/library/nginx:latest" in 0.879149587s
…

キャッシュに保存されたコンテナイメージに想定されるイメージ pull のレイテンシは、イメージサイズに関係なく大幅に短縮されます。

GKE Standard を使用する

GKE Standard クラスタとノードプールを作成するには、次の手順を完了します。セカンダリブートディスクにコンテナイメージをプリロードするのか、データをプリロードするかに応じて、[イメージ] タブまたは [データ] タブを選択します。

画像

セカンダリブートディスクを構成するには、Google Cloud CLI または Terraform を使用します。

gcloud

イメージストリーミングを有効にして GKE Standard クラスタを作成します。
```
gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=VERSION \
    --enable-image-streaming
```
次のように置き換えます。
- CLUSTER_NAME: クラスタの名前。
- LOCATION: クラスタのロケーション。
- VERSION: 使用する GKE のバージョン。GKE のバージョンは 1.28.3-gke.1067000 以降にする必要があります。
同じプロジェクトにセカンダリブートディスクを含むノードプールを作成します。
```
gcloud container node-pools create NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--location LOCATION \
--enable-image-streaming \
--secondary-boot-disk=disk-image=global/images/DISK_IMAGE_NAME,mode=CONTAINER_IMAGE_CACHE
```
次のように置き換えます。
- NODE_POOL_NAME: ノードプールの名前。
- CLUSTER_NAME: 既存のクラスタの名前。
- LOCATION: クラスタのコンピューティングゾーン（カンマ区切り）。
- DISK_IMAGE_NAME: ディスクイメージの名前。
別のプロジェクトのディスクイメージからセカンダリブートディスクを含むノードプールを作成するには、別のプロジェクトでセカンダリブートディスクを使用するの手順を完了します。

Pod テンプレートに nodeSelector を追加します。

nodeSelector:
    cloud.google.com/gke-nodepool: NODE_POOL_NAME

セカンダリブートディスクキャッシュが使用中であることを確認します。
```
kubectl get events --all-namespaces
```
出力は次のようになります。
```
75s       Normal      SecondaryDiskCachin
node/gke-pd-cache-demo-default-pool-75e78709-zjfm Image
gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary disk cache
```
注: イベントの量が多い場合、Kubernetes によってイベントがスロットリングされる可能性があります。イベントが欠落しているからといって、セカンダリブートディスクが使用されなかったことを示すものではありません。次の手順では、信頼性の高い方法でセカンダリブートディスクが使用されたことを確認します。
セカンダリブートディスクキャッシュが使用中であることを確認する信頼性の高い方法は次のとおりです。

次のログ名を使用して、対象のノードのログをクエリします。
```
logName="projects/PROJECT_ID/logs/gcfs-snapshotter"
```
PROJECT_ID は、実際の Google Cloud プロジェクト ID に置き換えます。

Image gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary boot disk caching by 100.0%... のようなログは、セカンダリブートディスクキャッシュが使用されたことを示します。
次のコマンドを実行して、イメージ pull レイテンシを確認します。
```
kubectl describe pod POD_NAME
```
POD_NAME は、Pod の名前で置き換えます。

出力は次のようになります。
```
…
  Normal  Pulled     15m   kubelet            Successfully pulled image "docker.io/library/nginx:latest" in 0.879149587s
…
```

キャッシュに保存されたコンテナイメージの想定されるイメージ pull レイテンシは、イメージサイズに関係なく数秒以内にする必要があります。

Terraform

Terraform を使用してデフォルトノードプールを持つクラスタを作成するには、次の例をご覧ください。

resource "google_container_cluster" "default" {
  name               = "default"
  location           = "us-central1-a"
  initial_node_count = 1

  # secondary_boot_disks require GKE 1.28.3-gke.106700 or later, which should
  # be true for all release channels apart from EXTENDED.
  # If required, Use `release_channel = "EXTENDED"` and set `min_master_version`.
}

同じプロジェクトにセカンダリブートディスクを含むノードプールを作成します。

resource "google_container_node_pool" "secondary-boot-disk-container" {
  name               = "secondary-boot-disk-container"
  location           = "us-central1-a"
  cluster            = google_container_cluster.default.name
  initial_node_count = 1

  node_config {
    machine_type = "e2-medium"
    image_type   = "COS_CONTAINERD"
    gcfs_config {
      enabled = true
    }
    secondary_boot_disks {
      disk_image = ""
      mode       = "CONTAINER_IMAGE_CACHE"
    }
  }
}

Terraform の使用方法の詳細については、GKE での Terraform のサポートをご覧ください。

Pod テンプレートに nodeSelector を追加します。

nodeSelector:
    cloud.google.com/gke-nodepool: NODE_POOL_NAME

セカンダリブートディスクキャッシュが使用中であることを確認します。

kubectl get events --all-namespaces

出力は次のようになります。

75s       Normal      SecondaryDiskCachin
node/gke-pd-cache-demo-default-pool-75e78709-zjfm Image
gcr.io/k8s-staging-jobsejt/pytorch-mnist:latest is backed by secondary disk cache

次のコマンドを実行して、イメージ pull レイテンシを確認します。
```
kubectl describe pod POD_NAME
```
POD_NAME は、Pod の名前で置き換えます。

出力は次のようになります。
```
…
  Normal  Pulled     15m   kubelet            Successfully pulled image "docker.io/library/nginx:latest" in 0.879149587s
…
```

キャッシュに保存されたコンテナイメージの想定されるイメージ pull レイテンシは、イメージサイズに関係なく数秒以内にする必要があります。

Terraform の使用方法の詳細については、GKE での Terraform のサポートをご覧ください。

データ

セカンダリブートディスクとプリロードデータを構成するには、Google Cloud CLI または Terraform を使用します。

gcloud

イメージストリーミングを有効にして GKE Standard クラスタを作成します。
```
gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --cluster-version=VERSION \
    --enable-image-streaming
```
次のように置き換えます。
- CLUSTER_NAME: クラスタの名前。
- LOCATION: クラスタのロケーション。
- VERSION: 使用する GKE のバージョン。GKE バージョンは、1.28.3-gke.1067000 以降である必要があります。
--secondary-boot-disk フラグを使用して、セカンダリブートディスクを含むノードプールを作成します。
```
gcloud container node-pools create NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--location LOCATION \
--enable-image-streaming \
--secondary-boot-disk=disk-image=global/images/DISK_IMAGE_NAME
```
次のように置き換えます。
- NODE_POOL_NAME: ノードプールの名前。
- CLUSTER_NAME: 既存のクラスタの名前。
- LOCATION: クラスタのコンピューティングゾーン（カンマ区切り）。
- DISK_IMAGE_NAME: ディスクイメージの名前。
別のプロジェクトのディスクイメージからセカンダリブートディスクを含むノードプールを作成するには、別のプロジェクトでセカンダリブートディスクを使用するの手順を完了します。

プリロードされたデータを含むセカンダリディスクが各ノードに存在するノードプールが作成されます。GKE は、セカンダリブートディスクをノードにアタッチしてマウントします。
データにアクセスするには、hostPath ボリュームマウントを使用して、セカンダリブートディスクイメージを Pod コンテナにマウントします。/usr/local/data_path_sbd には、データを配置するコンテナ内のパスに設定します。
```
apiVersion: v1
kind: Pod
metadata:
  name: pod-name
spec:
  containers:
  ...
  volumeMounts:
  - mountPath: /usr/local/data_path_sbd
    name: data-path-sbd
...
volumes:
  - name: data-path-sbd
    hostPath:
        path: /mnt/disks/gke-secondary-disks/gke-DISK_IMAGE_NAME-disk
```
DISK_IMAGE_NAME は、ディスクイメージの名前に置き換えます。

注: セカンダリブートディスクは、同じノード上のすべてのコンテナで共有されます。1 つのコンテナによってセカンダリブートディスクに書き込まれたデータは、そのディスクをマウントするノードの他のすべてのコンテナに表示されます。意図しない変更を防ぐには、ボリュームを読み取り専用モードでマウントします。

Terraform

Terraform を使用してデフォルトノードプールを持つクラスタを作成するには、次の例をご覧ください。

resource "google_container_cluster" "default" {
  name               = "default"
  location           = "us-central1-a"
  initial_node_count = 1

  # secondary_boot_disks require GKE 1.28.3-gke.106700 or later, which should
  # be true for all release channels apart from EXTENDED.
  # If required, Use `release_channel = "EXTENDED"` and set `min_master_version`.
}

同じプロジェクトにセカンダリブートディスクを含むノードプールを作成します。

resource "google_container_node_pool" "secondary-boot-disk-data" {
  name               = "secondary-boot-disk-data"
  location           = "us-central1-a"
  cluster            = google_container_cluster.default.name
  initial_node_count = 1

  node_config {
    machine_type = "e2-medium"
    image_type   = "COS_CONTAINERD"
    gcfs_config {
      enabled = true
    }
    secondary_boot_disks {
      disk_image = ""
    }
  }
}

Terraform の使用方法の詳細については、GKE での Terraform のサポートをご覧ください。

データにアクセスするには、hostPath ボリュームマウントを使用して、セカンダリブートディスクイメージを Pod コンテナにマウントします。/usr/local/data_path_sbd には、データを配置するコンテナ内のパスに設定します。
```
apiVersion: v1
kind: Pod
metadata:
  name: pod-name
spec:
  containers:
  ...
  volumeMounts:
  - mountPath: /usr/local/data_path_sbd
    name: data-path-sbd
...
volumes:
  - name: data-path-sbd
    hostPath:
        path: /mnt/disks/gke-secondary-disks/gke-DISK_IMAGE_NAME-disk
```
DISK_IMAGE_NAME は、ディスクイメージの名前に置き換えます。

セカンダリブートディスクを使用したクラスタの自動スケーリング

ノードプールを作成し、セカンダリブートディスクでクラスタの自動スケーリングを構成するには、Google Cloud CLI を使用します。

  gcloud container node-pools create NODE_POOL_NAME \
      --cluster=CLUSTER_NAME \
      --location LOCATION \
      --enable-image-streaming \
      --secondary-boot-disk=disk-image=global/images/DISK_IMAGE_NAME,mode=CONTAINER_IMAGE_CACHE \
      --enable-autoscaling \
      --num-nodes NUM_NODES \
      --min-nodes MIN_NODES \
      --max-nodes MAX_NODES

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

NODE_POOL_NAME: ノードプールの名前。
CLUSTER_NAME: 既存のクラスタの名前。
LOCATION: クラスタのコンピューティングゾーン（カンマ区切り）。
DISK_IMAGE_NAME: ディスクイメージの名前。
MIN_NODES: 指定したノードプールで自動的にスケーリングするゾーンの最小ノード数。GKE バージョン 1.24 以降でノードプール全体の最小ノード数を指定するには、--total-min-nodes を使用します。フラグ --total-min-nodes、--total-max-nodes は、フラグ --min-nodes、--max-nodes と相互に排他的です。
MAX_NODES: 指定したノードプールで自動的にスケーリングするゾーンの最大ノード数。GKE バージョン 1.24 以降でノードプール全体のノードの最大数を指定するには、--total-max-nodes を使用します。フラグ --total-min-nodes、--total-max-nodes は、フラグ --min-nodes、--max-nodes と相互に排他的です。

セカンダリブートディスクを使用したノードの自動プロビジョニング

GKE 1.30.1-gke.1329000 以降では、ワークロードのリソース需要を満たすためにノードプールを自動的に作成および削除するよう、ノードの自動プロビジョニングを構成できます。

次のように、GKE ノードの自動プロビジョニング用のセカンダリブートディスクにディスクイメージ許可リストカスタムリソースを作成します。
```
apiVersion: "node.gke.io/v1"
kind: GCPResourceAllowlist
metadata:
  name: gke-secondary-boot-disk-allowlist
spec:
  allowedResourcePatterns:
  - "projects//global/images/.*"
```
PROJECT_ID は、ディスクイメージをホストするプロジェクト ID に置き換えます。
クラスタに許可リストカスタムリソースをデプロイするには、次のコマンドを実行します。
```
kubectl apply -f ALLOWLIST_FILE
```
ALLOWLIST_FILE は、マニフェストファイル名に置き換えます。
セカンダリブートディスクを使用するように Pod ノードセレクタを更新します。
```
nodeSelector:
    cloud.google.com.node-restriction.kubernetes.io/gke-secondary-boot-disk-DISK_IMAGE_NAME:CONTAINER_IMAGE_CACHE.PROJECT_ID
```
次のように置き換えます。
- DISK_IMAGE_NAME: ディスクイメージの名前。
- PROJECT_ID: ディスクイメージをホストするプロジェクト ID。

別のプロジェクトでセカンダリブートディスクを使用する

セカンダリブートディスクを含むノードプールを作成する場合は、--secondary-boot-disk フラグを使用して、別のプロジェクトのディスクイメージを使用するように GKE に指示できます。

別のプロジェクトのディスクイメージから、セカンダリブートディスクを含むノードプールを作成するには、--secondary-boot-disk フラグを使用します。例:
```
gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location LOCATION \
    --enable-image-streaming \
    --secondary-boot-disk=disk-image=projects/IMAGE_PROJECT_ID/global/images/DISK_IMAGE_NAME,mode=CONTAINER_IMAGE_CACHE
```
次のように置き換えます。
- DISK_IMAGE_NAME: ディスクイメージの名前。
- IMAGE_PROJECT_ID: ディスクイメージが属するプロジェクトの名前。
プリロードされたデータを含むセカンダリディスクが各ノードに存在するノードプールが作成されます。これにより、セカンダリブートディスクがノードにアタッチされ、マウントされます。
クラスタサービスアカウントに Compute イメージユーザーのロールを追加して、別のプロジェクトに属するディスクイメージへのアクセス権を付与します。
- デフォルトのコンピューティングサービスアカウント: CLUSTER_PROJECT_NUMBER@cloudservices.gserviceaccount.com
- GKE サービスアカウント: service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
```
gcloud projects add-iam-policy-binding IMAGE_PROJECT_ID \
    --member serviceAccount:CLUSTER_PROJECT_NUMBER@cloudservices.gserviceaccount.com \
    --role roles/compute.imageUser

gcloud projects add-iam-policy-binding IMAGE_PROJECT_ID \
    --member serviceAccount:service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role roles/compute.imageUser
```

次のステップ

イメージストリーミングを使用してコンテナイメージを pull するで、ワークロードで必要なイメージデータをストリーミングしてコンテナイメージを pull します。
NVIDIA Collective Communication Library（NCCL）Fast Socket プラグインの使用方法については、NCCL Fast Socket を使用してワークロードの効率を向上させるをご覧ください。

セカンダリ ブートディスクを使用してデータまたはコンテナ イメージをプリロードする コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

概要

セカンダリ ブートディスクの仕組み

始める前に

要件

制限事項

料金

セカンダリ ブートディスク イメージを準備する

イメージ

データ

セカンダリ ブートディスクを構成する

GKE Autopilot を使用する

プロジェクトでディスク イメージを許可する

セカンダリ ブートディスクを使用するように Pod ノードセレクタを更新する

GKE Standard を使用する

画像

gcloud

Terraform

データ

gcloud

Terraform

セカンダリ ブートディスクを使用したクラスタの自動スケーリング

セカンダリ ブートディスクを使用したノードの自動プロビジョニング

別のプロジェクトでセカンダリ ブートディスクを使用する

次のステップ

セカンダリブートディスクを使用してデータまたはコンテナイメージをプリロードする
コレクションでコンテンツを整理必要に応じて、コンテンツの保存と分類を行います。

セカンダリブートディスクの仕組み

セカンダリブートディスクイメージを準備する

セカンダリブートディスクを構成する

プロジェクトでディスクイメージを許可する

セカンダリブートディスクを使用するように Pod ノードセレクタを更新する

セカンダリブートディスクを使用したクラスタの自動スケーリング

セカンダリブートディスクを使用したノードの自動プロビジョニング

別のプロジェクトでセカンダリブートディスクを使用する