ローカル SSD（ソリッド ステート ドライブ）は、単一の Compute Engine VM にマウントできる固定サイズの SSD ドライブです。GKE のローカル SSD を使用すると、クラスタ内のすべてのノードにアタッチされている永続的ではない（エフェメラル）ストレージの高いパフォーマンスを実現できます。ローカル SSD は、標準的なディスクより高いスループットと低いレイテンシも実現します。
バージョン 1.25.3-gke.1800 以降では、ローカル エフェメラル ストレージまたは raw ブロック ストレージに NVMe インターフェースを備えたローカル SSD を使用するように GKE ノードプールを構成できます。
Standard クラスタで GKE を使用している場合は、ノードプールを作成するときにローカル SSD ボリュームをノードにアタッチできます。これにより、emptyDir Volumes またはローカル PersistentVolumes を使用するワークロードでエフェメラル ストレージのパフォーマンスが向上します。クラスタのマシンタイプ上限とプロジェクトの割り当ての枠内で、ローカル SSD を使用したノードプールを作成できます。
ローカル SSD ディスクは 1 つのノードのみにアタッチされ、ノード自体はエフェメラルになります。ワークロードはいつでも別のノードでスケジュールできます。
パフォーマンスやマシンタイプごとに許可される SSD ディスクの数など、ローカル SSD の利点と上限の詳細については、Compute Engine ドキュメントのローカル SSD をご覧ください。
GKE にローカル SSD を選択する理由
ローカル SSD は、ワークロードに次のいずれかの要件が存在する場合に適しています。
- AI や ML、分析、バッチ処理、ローカル キャッシュ、インメモリ データベースなど、データをダウンロードして処理するアプリケーションを実行する必要がある場合。
- アプリケーションに特殊なストレージの要件があり、高性能なエフェメラル ストレージで raw ブロック アクセスが必要な場合。
- 特別なデータ アプリケーションを実行し、Pod のノードレベルのキャッシュなどのローカル SSD ボリュームを運用する必要がある場合。このアプローチを使用すると、Aerospike や Redis などのインメモリ データベース アプリケーションのパフォーマンスを改善できます。
エフェメラル ストレージ
ノードのエフェメラル ストレージ用にローカル SSD をプロビジョニングするには、--ephemeral-storage-local-ssd オプションを使用することをおすすめします（これは、第 3 世代のマシンシリーズを使用している場合のデフォルトです）。このアプローチでは、ノードのエフェメラル ストレージを構成する emptyDir ボリューム、コンテナに書き込み可能なレイヤ、イメージがまとめてローカル SSD 上に配置されます。メリットとしては、I/O 帯域幅がデフォルトの Persistent Disk よりも向上し、Pod の起動時間が短くなります。
ノードのエフェメラル ストレージにローカル SSD を使用すると、ブートディスクのローカル SSD ボリュームは他の用途に使用できません。特権 Daemonset、HostPath などのメカニズムを使用して /dev/nvme* などのローカル SSD デバイスを直接変更しないでください。このような操作を行うと、ノードで障害が発生する可能性があります。ローカル SSD ボリュームを細かく制御する必要がある場合は、代わりに raw ブロックを使用してください。
ブロック デバイス ストレージ
ブロック デバイス ストレージでは、固定サイズのブロック内のデータにランダムにアクセスできます。一部の特殊なアプリケーションでは、ファイル システム レイヤから不要なオーバーヘッドが発生するなどの理由で、ブロック デバイス ストレージに直接アクセスする必要があります。
ブロック デバイス ストレージを使用する一般的なシナリオは次のとおりです。
- 基盤となるストレージ上でデータが直接編成されるデータベース。
- なんらかのストレージ サービス（ソフトウェア定義のストレージ システム）を実装するソフトウェア。
GKE バージョン v1.25.3-gke.1800 以降では、--local-nvme-ssd-block オプションを使用することで、raw ブロックのローカル NVMe SSD がアタッチされたクラスタとノードプールを作成できます。任意のファイル システム（ZFS や HDFS）をフォーマットして RAID を構成することで、ブロック ストレージをカスタマイズできます。このオプションは、ローカル SSD を基盤とするブロック ストレージへのアクセスを必要とするワークロードを実行するために、追加の制御が必要な場合に適しています。
統合データ キャッシュで Pod 間でデータを共有し、データがノードのライフサイクルに関連付けられている場合は、ローカル SSD でブロック アクセス アプローチを使用することもできます。これを行うには、RAID 構成で DaemonSet をインストールしてファイルシステムをフォーマットし、ローカル PersistentVolume を使用して Pod 間でデータを共有します。
マシンの要件
GKE クラスタとノードプールにローカル SSD をプロビジョニングする方法は、基盤となるマシンタイプによって異なります。GKE は、Compute Engine の第 1 世代、第 2 世代、第 3 世代のマシンシリーズでローカル SSD ボリュームをサポートしています。ローカル SSD ボリュームには、n1-standard-1 以上のマシンタイプが必要です。デフォルトのマシンタイプ e2-medium はサポートされていません。マシンシリーズは、マシンタイプ名の番号で識別できます。たとえば、N1 マシンは第 1 世代、N2 マシンは第 2 世代です。使用可能なマシンシリーズとタイプのリストについては、Compute Engine ドキュメントのマシン ファミリーのリソースと比較ガイドをご覧ください。
第 1 世代と第 2 世代のマシンシリーズの要件
ローカル SSD を第 1 世代または第 2 世代のマシンシリーズで使用するには、クラスタまたはノードプールで GKE バージョン 1.25.3-gke.1800 以降を実行している必要があります。
第 1 世代または第 2 世代のマシンシリーズでローカル SSD をプロビジョニングするには、VM で使用するローカル SSD ボリュームの数を指定します。マシンシリーズと対応するローカル SSD の許容数については、Compute Engine ドキュメントの有効なローカル SSD の選択をご覧ください。
第 3 世代マシンシリーズの要件
ローカル SSD を第 3 世代のマシンシリーズで使用する場合は、クラスタまたはノードプールで次のいずれかの GKE バージョンが実行されている必要があります。
- 1.25.13-gke.200～1.26
- 1.26.8-gke.200～1.27
- 1.27.5-gke.200～1.28
- 1.28.1-gke.200～1.29
第 3 世代マシンシリーズの場合、各マシンタイプは「ローカル SSD なし」または「固定量のローカル SSD ボリューム」のいずれかで事前構成されています。ローカル SSD ボリュームの数は指定しません。クラスタで使用可能なローカル SSD の容量は、VM シェイプの一部として暗黙的に定義されます。
マシンシリーズと対応するローカル SSD の許容数については、Compute Engine ドキュメントの有効なローカル SSD の選択をご覧ください。
ローカル SSD ボリュームの使用パターン
クラスタでローカル SSD を使用する際の一般的な手順は次のとおりです。
- ローカル SSD が接続されたノードプールをプロビジョニングする: ローカル SSD が接続された GKE ノードプールを作成するには、
create clusterコマンドを呼び出すときに、エフェメラル ストレージまたは raw ブロック ストレージのいずれかのパラメータを使用します。ローカル SSD パラメータを設定すると、選択したパラメータに応じて、ローカル SSD が接続され、ローカル エフェメラル ストレージまたは raw ブロック ストレージとして構成された GKE ノードプールが作成されます。ローカル SSD のプロビジョニング オプションの詳細については、ローカル SSD パラメータをご覧ください。 - ローカル SSD ボリュームからのデータへのアクセス: ローカル SSD ボリュームのデータを使用するには、emptyDir やローカル永続ボリュームなどの Kubernetes 構造を使用できます。これらのオプションの詳細については、ローカル SSD アクセスをご覧ください。
GKE のローカル SSD パラメータ
次の表は、クラスタにローカル SSD ストレージをプロビジョニングするために GKE が提供している推奨パラメータをまとめたものです。gcloud CLI を使用して、これらのパラメータを渡すことができます。
| ローカル SSD タイプ | gcloud CLI コマンド | GKE の可用性 | ローカル SSD プロファイル |
|---|---|---|---|
| エフェメラル ストレージのローカル SSD | gcloud container clusters create |
v1.25.3-gke.1800 以降 |
ストレージ テクノロジー: NVMe Pod 間で共有されるデータ: なし データ ライフサイクル: Pod RAID 構成のサイズと必要性: 最大 9 TiBGKE は内部で RAID を自動的に構成します。 形式: ファイル システム（Kubernetes emptyDir） Kubernetes スケジューラの統合: デフォルトでは完全に統合されています。Kubernetes スケジューラは、ノードを配置する前にノード上のスペースを確保し、必要に応じてノードをスケーリングします。 この API パラメータの使用方法については、ローカル SSD を使用するエフェメラル ストレージをプロビジョニングして使用するをご覧ください。 |
| ローカル NVMe SSD ブロック | gcloud container clusters create |
v1.25.3-gke.1800 以降 |
ストレージ テクノロジー: NVMe Pod 間でのデータ共有: あり、ローカル PV 経由。 データ ライフサイクル: ノード RAID 構成のサイズと必要性: 最大 9 TiBサイズの大きい RAID は手動で構成する必要があります。 形式: 未加工のブロック Kubernetes スケジューラの統合: デフォルトではできません。ノード上の容量を確保し、ノイジー ネイバーを処理する必要があります。ローカル PV にオプトインすると、スケジューリングが統合されます。 この API パラメータの使用方法については、ローカル SSD を使用する raw ブロック ストレージをプロビジョニングして使用するをご覧ください。 |
既存のローカル SSD パラメータのサポート
次の表は、既存のローカル SSD パラメータと推奨される代替パラメータをまとめたものです。
| 既存のローカル SSD パラメータ | gcloud CLI コマンド | ローカル SSD プロファイル | ローカル SSD パラメータの推奨される一般提供バージョン |
|---|---|---|---|
| ローカル SSD 数のパラメータ | gcloud container clusters create |
ストレージ テクノロジー: SCSI Pod 間でのデータ共有: あり、ローカル PV 経由。 データ ライフサイクル: ノード RAID 構成のサイズと必要性: 375 GiB。サイズの大きい RAID は手動で構成する必要があります。 形式: ファイル システム（ext-4） Kubernetes スケジューラの統合: デフォルトではできません。ノード上の容量を確保し、ノイジー ネイバーを処理する必要があります。ローカル PV にオプトインすると、スケジューリングが統合されます。 |
gcloud container clusters create |
| エフェメラル ストレージ パラメータ（ベータ版） | gcloud beta container clusters create |
ストレージ テクノロジー: NVMe Pod 間で共有されるデータ: なし データ ライフサイクル: Pod RAID 構成のサイズと必要性: 最大 9 TiBGKE は内部で RAID を自動的に構成します。 形式: ファイル システム（Kubernetes emptyDir） Kubernetes スケジューラの統合: デフォルトでは完全に統合されています。Kubernetes スケジューラは、ノードを配置する前にノード上のスペースを確保し、必要に応じてノードをスケーリングします。 |
gcloud container clusters create |
| ローカル SSD ボリューム パラメータ（アルファ版） | gcloud alpha container clusters create |
ストレージ テクノロジー: NVMe または SCSI Pod 間で共有されるデータ: なし データ ライフサイクル: ノード RAID 構成のサイズと必要性: 375 GiB。サイズの大きい RAID は手動で構成する必要があります。 形式: ファイル システム（ext-4）または raw ブロック Kubernetes スケジューラの統合: デフォルトでは統合できません。ノード上の容量を確保し、ノイジー ネイバーを処理する必要があります。 |
gcloud container clusters create |
ローカル SSD へのアクセス
ローカル SSD ボリュームには、次のいずれかの方法でアクセスできます。
emptyDir Volume
GKE バージョン v1.25.3-gke.1800 以降では、エフェメラル ストレージは、ローカル SSD を基盤とする emptyDir ボリュームとして使用できます（--ephemeral-storage-local-ssd オプションを使用）。高パフォーマンスの一時的なスクラッチ領域が必要なアプリケーションを含め、ほとんどの場合はこの方法をおすすめします。
GKE では、NVMe インターフェースを使用して、ローカル SSD にノードのエフェメラル ストレージをマウントするようにノードプールを構成できます。
詳細については、こちらの例をご覧ください。
ローカル永続ボリューム
ローカル永続ボリュームは、単一のノードにアタッチされたローカル ディスクを表します。ローカル永続ボリュームを使用すると、Pod 間でローカル SSD リソースを共有できます。ローカル ディスクはローカル SSD ディスクであるため、データは引き続きエフェメラルです。
次のいずれかがクラスタで実行される場合は、この方法をおすすめします。
- StatefulSets と volumeClaimTemplates を使用するワークロードの場合。
- ノードプールを共有するワークロードの場合。各ローカル SSD ボリュームは PersistentVolumeClaim で予約でき、特定の HostPath は Pod 仕様で直接エンコードされません。
- Pod で同じローカル SSD に対するデータ グラビティが必要とされる場合。Pod は常にローカルの PersistentVolume と同じノードにスケジュールされます。
詳細については、こちらの例とオープンソースの Kubernetes Volume のドキュメントをご覧ください。
制限事項
アプリケーションで、ローカル SSD ボリューム上のデータにアクセスできない問題を適切に処理する必要があります。ローカル SSD ディスクに書き込まれたデータは、Pod またはノードが削除、修復、アップグレードされた場合、または回復不能なエラーが発生した場合には保持されません。
エフェメラル ストレージのローカル SSD パラメータは、Pod ベースのデータ ライフサイクルを持つようにローカル SSD ボリュームを構成します。NVMe ローカル SSD ブロック パラメータは、ノードベースのデータ ライフサイクルを持つようにローカル SSD ボリュームを構成します。
永続ストレージが必要な場合は、耐久性に優れたストレージ オプション（Persistent Disk、Filestore、Cloud Storage など）を使用することをおすすめします。リージョン レプリカを使用して、クラスタのライフサイクルまたはアプリケーションのライフサイクルのオペレーション中にデータ損失が発生するリスクを最小限に抑えることもできます。
ローカル SSD の構成設定は、ノードプールの作成後に変更することはできません。既存のノードプールのローカル SSD 構成の有効化、無効化、更新はできません。変更するには、ノードプールを削除して新しいノードプールを再作成する必要があります。
emptyDir を使用する Pod では、ローカル SSD を透過的に使用します。ただし、対象のノードプール内に存在するすべてのノード上のすべての Pod がこれに該当します。GKE では、同じノードプール内で、ローカル SSD を基盤とするローカル SSD emptyDir Volume を使用する Pod と、ノード ブートディスクを基盤とする emptyDir Volume を使用する Pod はサポートされていません。ノード ブートディスクを基盤とする emptyDir Volume を使用するワークロードがある場合は、別のノードプールにワークロードをスケジュールします。
Autopilot クラスタとノードの自動プロビジョニングは、ローカル SSD ではサポートされていません。
ストレージ最適化（Z3）VM で実行されるワークロードには、エフェメラル ストレージとしてローカル SSD を使用することをおすすめします。Z3 ノードは、メンテナンス イベント中に終了します。そのため、メンテナンス イベント中は、これらのノードのローカル SSD のデータが使用できなくなる可能性があります。また、メンテナンス後のデータ復元は保証されません。