専用の永続ディスクをエフェメラルボリュームとして使用する

Autopilot Standard

このページでは、Compute Engine 永続ディスクなどの外部ストレージハードウェアを Google Kubernetes Engine（GKE）ワークロードのエフェメラルボリュームとして使用する方法について説明します。Kubernetes の Volume と StorageClass に精通している必要があります。

Kubernetes でエフェメラルストレージを使用するタイミング

エフェメラルストレージは、データ処理パイプライン、ML ジョブ、バッチ処理、ローカルキャッシュ、分析など、ワークロードがアプリケーションのライフサイクル中にのみデータを必要とする状況で役立ちます。デフォルトでは、GKE ノードのブートディスクの一部を Pod のエフェメラルストレージとして使用できます。このアプローチを採用する場合は、慎重にスペースプランニングを行う必要があります。

Kubernetes の汎用エフェメラルボリュームでは、PersistentVolumeClaim を使用して、Pod のエフェメラルストレージを明示的にリクエストできます。GKE は Compute Engine 永続ディスクを動的にプロビジョニングし、ディスクをノードにアタッチします。このタイプのエフェメラルストレージは、次のような状況で役立ちます。

ワークロードのパフォーマンス要件が高く、ストレージハードウェアを制御する必要がある。
コンテナ固有の短期的なエフェメラルストレージが必要。
emptyDir を使用してエフェメラルストレージをプロビジョニングしたくない。emptyDir ボリュームは、複数のコンテナでエフェメラルストレージのデータを共有する場合に便利です。
GKE の組み込みデフォルト値よりも多くのエフェメラルストレージ容量が必要。
Standard モードの GKE クラスタで、ノードブートディスクのサイズとタイプを事前に決めておく必要がない。

GKE のエフェメラルストレージのタイプ

一般に、Pod とコンテナでは、ブートディスクのストレージ容量や専用の永続ディスクをエフェメラルストレージとして使用できます。次の表に、その違いを示します。

ストレージの種類使い方説明

ブートディスク - 永続ディスク

ストレージの種類	使い方	説明
ブートディスク - 永続ディスク	Pod 仕様で `emptyDir` を使用してボリュームをマウントし、必要な容量をリクエストします。手順については、ボリュームの作成をご覧ください。	リクエストされたエフェメラルストレージは、ノードブートディスクの予約済み部分から取得されます。これは、Autopilot クラスタと Standard クラスタの両方でデフォルトになっています。 Pod でエフェメラルストレージリクエストが少ない場合や、Pod 内の複数のコンテナ間でエフェメラルデータを共有する場合に使用します。 Autopilot リクエストは 10 MiB～10 GiB の範囲で指定する必要があります。ストレージハードウェアタイプは事前構成されています。 Standard サイズの上限はありませんが、ノードのブートディスクサイズとストレージハードウェアのタイプを慎重に計画する必要があります。 GKE がノードブートディスク内のエフェメラルストレージの予約を計算する方法の詳細については、ローカルエフェメラルストレージの予約をご覧ください。
ローカル SSD ディスク	ローカル SSD ディスクと互換性のあるマシンシリーズがアタッチされたノードプールを作成します。 `emptyDir` を使用して、必要な容量でボリュームをマウントします。 nodeSelector を使用して、ローカル SSD ディスクがアタッチされているノードに Pod を配置します。手順については、ローカル SSD を使用したエフェメラルストレージのプロビジョニングをご覧ください。	ローカル SSD ディスクは、Standard モードの GKE クラスタと A100（80 GB）GPU を実行する Autopilot ノードでサポートされる固定の増分値（375 GB）を使用します。高スループットのエフェメラルストレージが必要な場合に使用します。詳細については、GKE のローカル SSD についてをご覧ください。
専用の永続ディスク	必要に応じて、ハードウェア用の Kubernetes StorageClass を作成します。 Pod 仕様で `ephemeral` ボリュームタイプを使用して、ボリュームをマウントします。このドキュメントでは、このエフェメラルストレージタイプをリクエストする手順を説明します。	Google Cloud は、リクエストされた外部ハードウェアを動的にプロビジョニングしてノードに接続し、リクエストされたボリュームを Pod にマウントします。 Pod にエフェメラルストレージリクエストが多い場合や、基盤となる永続ディスクタイプを制御する場合に使用します。これらのボリュームには次のプロパティがあります。 Autopilot モードと Standard モードで最大 64 TiB SSD バックボリュームなどの特殊なハードウェアがサポートされています。ネットワーク接続ストレージ。 `emptyDir` を使用してノードのブートディスクを共有する代わりに、Kubernetes Volume を使用してストレージを取得します。このエフェメラルボリュームタイプの詳細については、汎用エフェメラルボリュームをご覧ください。

Pod 仕様で emptyDir を使用してボリュームをマウントし、必要な容量をリクエストします。

手順については、ボリュームの作成をご覧ください。

リクエストされたエフェメラルストレージは、ノードブートディスクの予約済み部分から取得されます。これは、Autopilot クラスタと Standard クラスタの両方でデフォルトになっています。

Pod でエフェメラルストレージリクエストが少ない場合や、Pod 内の複数のコンテナ間でエフェメラルデータを共有する場合に使用します。

Autopilot

リクエストは 10 MiB～10 GiB の範囲で指定する必要があります。
ストレージハードウェアタイプは事前構成されています。

Standard

サイズの上限はありませんが、ノードのブートディスクサイズとストレージハードウェアのタイプを慎重に計画する必要があります。

GKE がノードブートディスク内のエフェメラルストレージの予約を計算する方法の詳細については、ローカルエフェメラルストレージの予約をご覧ください。

ローカル SSD ディスク

ローカル SSD ディスクと互換性のあるマシンシリーズがアタッチされたノードプールを作成します。
emptyDir を使用して、必要な容量でボリュームをマウントします。
nodeSelector を使用して、ローカル SSD ディスクがアタッチされているノードに Pod を配置します。

手順については、ローカル SSD を使用したエフェメラルストレージのプロビジョニングをご覧ください。

ローカル SSD ディスクは、Standard モードの GKE クラスタと A100（80 GB）GPU を実行する Autopilot ノードでサポートされる固定の増分値（375 GB）を使用します。

高スループットのエフェメラルストレージが必要な場合に使用します。

詳細については、GKE のローカル SSD についてをご覧ください。

専用の永続ディスク

必要に応じて、ハードウェア用の Kubernetes StorageClass を作成します。
Pod 仕様で ephemeral ボリュームタイプを使用して、ボリュームをマウントします。

このドキュメントでは、このエフェメラルストレージタイプをリクエストする手順を説明します。

Google Cloud は、リクエストされた外部ハードウェアを動的にプロビジョニングしてノードに接続し、リクエストされたボリュームを Pod にマウントします。

Pod にエフェメラルストレージリクエストが多い場合や、基盤となる永続ディスクタイプを制御する場合に使用します。これらのボリュームには次のプロパティがあります。

Autopilot モードと Standard モードで最大 64 TiB
SSD バックボリュームなどの特殊なハードウェアがサポートされています。
ネットワーク接続ストレージ。
emptyDir を使用してノードのブートディスクを共有する代わりに、Kubernetes Volume を使用してストレージを取得します。

このエフェメラルボリュームタイプの詳細については、汎用エフェメラルボリュームをご覧ください。

料金

このガイドで説明するように、汎用のエフェメラルボリュームを使用してプロビジョニングするストレージは、Compute Engine のディスク料金に基づいて課金されます。

始める前に

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

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 など）を防止できます。

バージョン 1.23 以降を実行する GKE Autopilot または Standard クラスタがあることを確認します。
Google Cloud プロジェクトに、ストレージハードウェア用の十分な割り当てがあることを確認します。割り当てを管理するには、プロジェクトの割り当てを表示するをご覧ください。

StorageClass を作成する

Kubernetes カスタム StorageClass を作成することで、価格とパフォーマンスの要件に基づいてプロビジョニングするストレージのタイプを指定できます。この手順は省略可能ですが、行うことをおすすめします。GKE のデフォルト StorageClass（pd-balanced 永続ディスクタイプ）を使用する場合は、この手順をスキップします。

次のマニフェストを ephemeral-pd-class.yaml として保存します。
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ephemeral-ssd
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: STORAGE_TYPE
```
STORAGE_TYPE は、必要な永続ディスクタイプの名前（pd-ssd など）で置き換えます。サポートされているタイプの一覧については、Compute Engine ドキュメントの永続ディスクタイプをご覧ください。

StorageClass を作成します。

kubectl create -f ephemeral-pd-class.yaml

Pod のエフェメラルストレージ容量をリクエストする

外部ハードウェアをエフェメラルストレージとしてプロビジョニングしてアタッチし、使用するには、対応するボリュームを Pod マニフェストに追加し、ボリュームマウントをコンテナ仕様に追加します。

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ephemeral-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      storage: ephemeral
  template:
    metadata:
      labels:
        storage: ephemeral
    spec:
      containers:
      - name: ephemeral-container
        image: nginx
        resources:
          requests:
            cpu: 500m
            memory: 2Gi
            ephemeral-storage: 2Gi
        volumeMounts:
        - mountPath: "/short-term"
          name: ephemeral-volume
      volumes:
      - name: ephemeral-volume
        ephemeral:
          volumeClaimTemplate:
            metadata:
              labels:
                type: ephemeral
            spec:
              accessModes: ["ReadWriteOnce"]
              storageClassName: "ephemeral-ssd"
              resources:
                requests:
                  storage: 1Ti

このマニフェストは、次のプロパティを使用して、ephemeral-volume という名前の新しい PersistentVolume をリクエストする新しい Kubernetes PersistentVolumeClaim を作成します。

spec.volumes.ephemeral: ephemeral ボリュームタイプ。
.spec.accessModes: ボリュームアクセスモード。Pod からの読み取り / 書き込みアクセス権と、ノード間のボリューム共有を決定します。この例では、ReadWriteOnce を使用して、PersistentVolume を単一ノードにマウントし、ノード上の 1 つ以上の Pod がアクセスできるようにします。詳細については、アクセスモードをご覧ください。
.spec.storageClassName: 作成した StorageClass の名前（省略可）。このフィールドを省略すると、GKE はデフォルトの StorageClass を使用し、pd-balanced 永続ディスクをプロビジョニングします。
.spec.resources.requests.storage: 必要なストレージ容量。

Deployment を作成します。

kubectl create -f ephemeral-ssd-deployment.yaml

GKE は、PersistentVolumeClaim の要件を満たす Compute Engine ディスクをプロビジョニングし、ディスクをノードにアタッチします。GKE は Volume を Pod にマウントし、リクエストされた容量をコンテナに提供します。

GKE がエフェメラルボリュームをマウントしたことを確認する

Pod でシェルセッションを作成します。

kubectl exec -it deploy/ephemeral-deployment -- bash

マウントされたボリュームを確認します。

df -h

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

Filesystem                Size      Used Available Use% Mounted on
...
/dev/sdb               1006.9G     28.0K   1006.8G   0% /short-term
/dev/sda1                94.3G      3.6G     90.6G   4% /etc/hosts
/dev/sda1                94.3G      3.6G     90.6G   4% /dev/termination-log
/dev/sda1                94.3G      3.6G     90.6G   4% /etc/hostname
/dev/sda1                94.3G      3.6G     90.6G   4% /etc/resolv.conf
...

シェルセッションを終了します。
```
exit
```

次のステップ

GKE で利用可能なストレージオプションについて学習する

専用の永続ディスクをエフェメラル ボリュームとして使用する

Kubernetes でエフェメラル ストレージを使用するタイミング

GKE のエフェメラル ストレージのタイプ

料金