このドキュメントでは、GKE がサポートするストレージ オプションと、ビジネスニーズに最適なオプションを選択するための重要な考慮事項について説明します。選択に適したマシン ファミリーを判断するには、マシンシリーズの比較をご覧ください。
GKE は、次のストレージ タイプとインテグレーションをサポートしています。
- Persistent Disk を使用したブロック ストレージ
- Google Cloud Hyperdisk を使用したブロック ストレージ
- Hyperdisk ストレージ プールを使用するブロック ストレージ
- ローカル SSD を使用したエフェメラル ブロック ストレージと未加工ブロック ストレージ
- ファイル ストレージ
- Cloud Storage FUSE を使用したオブジェクト ストレージ
- マネージド データベース
- ビルド アーティファクト
ブロック ストレージ(Persistent Disk)
Persistent Disk ボリュームは、Compute Engine によって管理される耐久性の高いネットワーク ストレージ デバイスであり、パソコンやサーバーの物理ディスクと同様に GKE クラスタからアクセスできます。クラスタに追加の保存容量が必要な場合は、ノードにより多くの Persistent Disk ボリュームをアタッチするか、既存の Persistent Disk ボリュームのサイズを変更できます。GKE に Persistent Disk を基盤とする PersistentVolumes を動的にプロビジョニングするか、手動でディスクをプロビジョニングできます。
このストレージ オプションは、GKE Autopilot クラスタと Standard クラスタでサポートされています。
デフォルトでは、Persistent Disk ボリュームはゾーンリソースです(リージョン内の単一のゾーンに保持されます)。リージョン Persistent Disk ボリュームを作成できます(同じリージョン内の 2 つのゾーンで保持します)。また、Persistent Disk ボリュームを読み取り専用として複数のノードに同時にアタッチすることもできます。これは、ゾーンとリージョンの両方の Persistent Disk ボリュームでサポートされています。
GKE の Persistent Disk ストレージは永続的です。つまり、ディスクに保存されているデータは、使用している Pod が終了しても保持されます。
Persistent Disk ストレージを使用する理由
クラスタが高パフォーマンス、高可用性で耐久性に優れたブロック ストレージにアクセスする必要がある場合は、Persistent Disk ストレージを使用します。通常、Persistent Disk ボリュームは単一の Pod にアタッチされます。このストレージ オプションは、ReadWriteOnce アクセスモードをサポートしています。GKE では、Persistent Disk ボリュームの構成がサポートされており、次のようなレイテンシとパフォーマンスのオプションが用意されています。
- バランス永続ディスク: 標準のエンタープライズ アプリケーションに適しています。パフォーマンスと費用のバランスが適度にとれるオプションです。ソリッド ステート ドライブ(SSD)によるバックアップです。GKE 1.24 以降を実行しているクラスタとノードでの動的ボリューム プロビジョニングのデフォルト オプションです。
- パフォーマンス永続ディスク: スケールアウト分析、データベース、永続キャッシュに適しています。パフォーマンス重視のワークロードに最適なオプションです。ソリッド ステート ドライブ(SSD)によるバックアップです。
- 標準永続ディスク: ビッグデータ、ビッグデータ コンピューティングのワークロードに適しています。最も費用対効果の高いディスクタイプです。標準ハードディスク ドライブ(HDD)によるバックアップです。
- エクストリーム Persistent Disk: SAP HANA や Oracle などのエンタープライズ アプリケーションに適しています。最大のインメモリ データベースのニーズを満たせるよう、非常に高いパフォーマンスを提供します。ソリッド ステート ドライブ(SSD)によるバックアップです。Persistent Disk が、十分なパフォーマンスを提供できないパフォーマンス重視のアプリケーションの場合は、Hyperdisk Extreme ディスクを使用します。
このストレージ オプションの使用を開始するには、次のリソースをご覧ください。
- 使用可能なディスクタイプについては、Compute Engine ドキュメントのストレージ オプションをご覧ください。
- Compute Engine Persistent Disk CSI ドライバは、GKE で Persistent Disk ストレージを使用する基本的な方法です。手順については、Compute Engine Persistent Disk CSI ドライバを使用をご覧ください。
ブロック ストレージ(Google Cloud Hyperdisk)
Hyperdisk ボリュームは、次世代の Google Cloud ブロック ストレージを使用します。Hyperdisk ボリュームを使用すると、ワークロードに合わせてブロック ストレージのパフォーマンスを動的に調整できます。アプリケーションごとに 1 秒あたりの入出力オペレーション(IOPS)とスループットを個別に構成でき、時間の経過とともに変化するパフォーマンスのニーズに適応できます。
このストレージ オプションは、GKE Autopilot クラスタと Standard クラスタでサポートされています。Hyperdisk ボリュームはゾーンリソースであり、リージョンの可用性が適用されます。GKE の Hyperdisk ストレージは永続的です。ディスクに保存されているデータは、使用している Pod が終了しても保持されます。
Hyperdisk ストレージを使用する理由
IOPS またはスループットを動的にサイズ変更し、調整する必要がある場合は、Hyperdisk ストレージを使用します。通常、Hyperdisk ボリュームは単一の Pod にアタッチされます。このストレージ オプションは、ReadWriteOnce
アクセスモードをサポートしています。料金とパフォーマンスのニーズに基づいて、GKE の次の Hyperdisk ストレージ オプションから選択できます。
- Hyperdisk Balanced: ほとんどのワークロードに最適です。これは、ほとんどのエンタープライズ アプリや基幹業務アプリ、データベース、ウェブサーバーのデプロイに適しています。
- Hyperdisk Throughput: 費用対効果に優れ、高スループット向けに最適化されています。これは、ユースケースでスケールアウト分析(Hadoop や Kafka など)、バックアップ サーバーからのコールドデータの復元、スループット重視でコストに敏感なワークロードに適しています。
- Hyperdisk Extreme: IOPS パフォーマンス向けに最適化されています。これは、データベース管理システムなどの高パフォーマンスのワークロードをデプロイする場合に適しています。
- Hyperdisk ML: モデルの重みをすばやく読み込む必要がある AI / ML トレーニング ワークロードと推論ワークロード用に最適化されています。このオプションは、レイテンシのボトルネックによる GPU / TPU リソースのアイドル状態を減らすために使用します。
Hyperdisk ストレージ オプションは、GKE Autopilot クラスタと Standard クラスタでサポートされています。
このストレージ オプションの使用を開始するには、以下のリソースをご覧ください。
- 概要については、GKE の Hyperdisk についてをご覧ください。
- 最大スループットと IOPS を含むディスクごとの上限については、Compute Engine ドキュメントのディスクごとの Hyperdisk の上限をご覧ください。
- クラスタで Hyperdisk Throughput ストレージと Extreme ストレージを設定して消費するには、Hyperdisk でストレージ パフォーマンスをスケールするをご覧ください。
ブロック ストレージ(Hyperdisk ストレージ プール)
Hyperdisk ストレージ プールは、GKE クラスタ内のディスクが使用できるストレージ リソース(容量、スループット、IOPS)の事前にプロビジョニングされたプールです。ストレージ リソースは、ストレージ プール内に作成するすべての Hyperdisk 間で共有されます。
GKE Standard クラスタでは、Hyperdisk ブートディスク(オペレーティング システム用)とアタッチされた Hyperdisk(データ ストレージ用)の両方をストレージ プールの一部にできます。GKE Autopilot クラスタは、ストレージ プール用にアタッチされた Hyperdisk のみをサポートします。
このストレージ オプションの使用を開始するには、以下のリソースをご覧ください。
- 概要については、Hyperdisk ストレージ プールについてをご覧ください。
- GKE クラスタに Hyperdisk ストレージ プールを設定するには、Hyperdisk ストレージ プールを使用してストレージのパフォーマンスとコストを最適化するをご覧ください。
エフェメラル ブロック ストレージと未加工ブロック ストレージ(ローカル SSD)
ローカル SSD ディスクは、ノードに直接アタッチされる物理ドライブです。パフォーマンスを改善できますが、一時的なものです。各ローカル SSD ボリュームは、特定のノードにアタッチされます。ボリュームを別のノードに移動することはできません。
このストレージ オプションは、GKE Standard クラスタでサポートされています。ローカル SSD の Autopilot サポートは、A2 Ultra A100 マシン、GKE 1.27 以降を実行しているクラスタとノードプールで、プレビュー版で利用可能です。
GKE のローカル SSD ストレージを基盤とするエフェメラル ストレージは、Pod のライフサイクルに関連付けられます。Pod が終了すると、その Pod に関連付けられているエフェメラル ストレージも削除されます。
ローカル SSD を使用する理由
GKE クラスタでのローカル SSD ストレージの使用は、データベースとリアルタイム分析用のホット キャッシュが必要な場合や、最小のレイテンシを提供するフラッシュに最適化されたエフェメラル ストレージが必要な場合に適しています。ローカル SSD ストレージは、AI / ML、バッチ処理、分析、メモリ内データベースのユースケースで Cloud Storage の前面のキャッシュ レイヤとして特に効果的です。
このストレージ オプションの使用を開始するには、以下のリソースをご覧ください。
- 概要については、GKE のローカル SSD ストレージについてをご覧ください。
- クラスタでローカル SSD ストレージを emptyDir として設定して使用するには、ローカル SSD を使用するエフェメラル ストレージをプロビジョニングして使用するをご覧ください。
- クラスタのローカル SSD ストレージをローカル PersistentVolume リソースとして設定して使用するには、ローカル SSD を使用する raw ブロック ストレージをプロビジョニングして使用するをご覧ください。
ファイル ストレージ
Filestore は、ネットワーク ファイル システム(NFS)へのアクセスを備えた、非構造化データ用のクラウドベースの共有ファイル システムを提供します。Filestore インスタンスは、Google Cloud でファイル サーバーとして機能し、GKE クラスタに ReadWriteMany
アクセス権を持つ耐久性の高いストレージを提供します。Filestore インスタンスはホストから切り離されているため、手動での操作は最小限に抑えられます。ボリュームのアタッチや切断を行うインフラストラクチャ オペレーションがないため、ワークロードのフェイルオーバーはシームレスに行われます。
このストレージ オプションは、GKE Autopilot クラスタと Standard クラスタでサポートされています。エンタープライズ サービス階層を使用する Filestore ストレージはデフォルトでリージョンの可用性を提供しますが、他のサービス階層にはゾーンの可用性があります。GKE の Filestore ストレージは永続的です。つまり、インスタンスに保存されているデータは、それを使用している Pod が終了しても保持されます。
Filestore ストレージを使用する理由
アプリケーションがネットワーク ファイル システム(NFS)へのアクセスと、複数のリーダーおよびライターを必要とする場合は、Filestore ストレージを使用します。このストレージ オプションは、コンテンツ マネジメント システム、アプリケーションの移行、データ分析、レンダリング、メディア処理を行う場合に適しています。
費用効率をさらに高めるため、GKE 向け Filestore マルチシェアを使用すると、10 GiB 以上の Filestore エンタープライズ ティア インスタンスを最大 80 の PersistentVolume と共有できます。
このストレージ オプションの使用を開始するには、以下のリソースをご覧ください。
- 概要については、GKE の Filestore サポートについてをご覧ください。
- Filestore CSI ドライバは、GKE で Filestore ストレージを使用する主要な方法です。手順については、Filestore CSI ドライバを使用して Filestore インスタンスにアクセスするをご覧ください。
- Filestore マルチシェアの手順については、GKE 向け Filestore マルチシェアを使用してストレージを最適化するをご覧ください。
オブジェクト ストレージ(Cloud Storage FUSE)
Cloud Storage は、バイナリデータやオブジェクト データ、blob、非構造化データ向けのオブジェクト ストアです。Cloud Storage FUSE CSI ドライバは、Cloud Storage FUSE と Kubernetes API のインテグレーションを管理し、既存の Cloud Storage バケットをボリュームとして使用します。Cloud Storage FUSE CSI ドライバを使用すると、バケットをファイル システムとして GKE ノードにマウントできます。
Cloud Storage FUSE の CSI ドライバは、GKE Autopilot クラスタと GKE Standard クラスタで ReadWriteMany
、ReadOnlyMany
、ReadWriteOnce
のアクセスモードをサポートしています。Cloud Storage オブジェクトには、リージョンの可用性があります。GKE の Cloud Storage データは永続的です。バケットに保存されているデータは、使用している Pod が終了しても保持されます。
Cloud Storage FUSE を使用する理由
Cloud Storage FUSE オプションは、ポータビリティを考慮して Cloud Storage の前にファイル セマンティクスを配置する必要がある場合に適しています。Cloud Storage FUSE は、機械学習(ML)トレーニングやモデルデータを Cloud Storage のオブジェクトとして保存し、アクセスするデベロッパーにもよく使用されています。
このストレージ オプションの使用を開始するには、以下のリソースをご覧ください。
- 概要については、Cloud Storage FUSE をご覧ください。
- クラスタで Google Cloud バケットを使用するには、Cloud Storage CSI FUSE ドライバを使用して Cloud Storage バケットにアクセスするをご覧ください。
マネージド データベース
Cloud SQL や Spanner などのマネージド データベースは、運用上のオーバーヘッドを削減し、Google Cloud インフラストラクチャ向けに最適化されています。マネージド データベースの保守や運用は、Kubernetes に直接デプロイするデータベースよりも簡単です。
マネージド データベースを使用する理由
Google Cloud マネージド データベースを使用すると、GKE 上のステートフル ワークロードが永続データにアクセスすると同時に、バックアップ、パッチ適用、スケーリングなどのメンテナンス タスクを自動化できます。データベースを作成、アプリを構築し、Google Cloud にスケールを実行させます。ただしこれは、正確なバージョンのデータベース、拡張機能、または目的のデータベースの正確なバージョンにアクセスできない可能性があることも意味します。
GKE では、次のような Google Cloud マネージド データベース サービスとの接続がサポートされています。
Cloud SQL: フルマネージドの MySQL、PostgreSQL、SQL Server データベース。Google Kubernetes Engine から接続するをご覧ください。
Spanner: 高い整合性と可用性を備えた、水平方向にスケーラブルなリレーショナル データベース。GKE Autopilot と Cloud Spanner を使用してアプリをデプロイするをご覧ください。
Memorystore for Redis: フルマネージドのインメモリ データストア サービス。Google Kubernetes Engine クラスタから Redis インスタンスへの接続をご覧ください。
このストレージ オプションの使用を開始するには、以下のリソースをご覧ください。
- Google Cloud のデータベース オプションについての説明。
- GKE でホストされているマネージド データベースまたはコンテナ化されたデータベースを使用する場合の考慮事項は、GKE でデータベースのデプロイを計画するをご覧ください。
ビルド アーティファクト(Artifact Registry)
Artifact Registry は、ビルドおよびデプロイしたコンテナ イメージ、OS パッケージ、言語パッケージ用のリポジトリ マネージャーです。
Artifact Registry を使用する理由
Artifact Registry は、非公開コンテナ イメージ、Helm チャート、およびその他のビルド アーティファクトの保存に適しています。
Artifact Registry Docker リポジトリから GKE にイメージを pull するには、Artifact Registry ドキュメントの Google Kubernetes Engine へのデプロイをご覧ください。
次のステップ
- ブログ投稿 Google Cloud でのストレージ オプションのマップを読む。
- クラウド ワークロードに最適なストレージ戦略を設計する。
- GKE で Kubernetes ストレージの抽象化を使用する方法を理解する: PersistentVolume、StatefulSet
- GKE 上のデータのリソースページで、GKE と統合できるデータ ソリューションを確認する。