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


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

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

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

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

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

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

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

ストレージの種類 使い方 説明
ブートディスク - 永続ディスク

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

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

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

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

Autopilot

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

Standard

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

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

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

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

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

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

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

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

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

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

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

  • Autopilot モードと Standard モードで最大 64 TiB。
  • Pod のエフェメラル ストレージ リクエストは最大 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 を実行して最新のバージョンを取得する。
  • バージョン 1.23 以降を実行する GKE Autopilot または標準クラスタがあることを確認します。
  • Google Cloud プロジェクトに、ストレージ ハードウェア用の十分な割り当てがあることを確認します。割り当てを管理するには、プロジェクトの割り当てを表示するをご覧ください。

StorageClass の作成

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

  1. 次のマニフェストを 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 は、必要な Persistent Disk タイプの名前(pd-ssd など)で置き換えます。サポートされているタイプの一覧については、Compute Engine ドキュメントの Persistent Disk タイプをご覧ください。

  2. StorageClass を作成します。

    kubectl create -f ephemeral-pd-class.yaml
    

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

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

  1. 次のマニフェストを 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 Persistent Disk をプロビジョニングします。
    • .spec.resources.requests.storage: 必要なストレージ容量。
  2. Deployment を作成します。

    kubectl create -f ephemeral-ssd-deployment.yaml
    

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

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

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

    kubectl exec -it deploy/ephemeral-deployment -- bash
    
  2. マウントされたボリュームを確認します。

    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
    ...
    
  3. シェル セッションを終了します。

    exit
    

次のステップ