GKE クラスタのストレージの概要

このドキュメントでは、GKE がサポートするストレージ オプションと、ビジネスニーズに最適なオプションを選択するための重要な考慮事項について説明します。

GKE は、次のストレージ タイプとインテグレーションをサポートしています。

ブロック ストレージ（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 ディスクを使用します。

このストレージ オプションの使用を開始するには、次のリソースをご覧ください。

ブロック ストレージ（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 クラスタでサポートされています。

このストレージ オプションの使用を開始するには、以下のリソースをご覧ください。

エフェメラル ブロック ストレージと未加工ブロック ストレージ（ローカル 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 の前面のキャッシュ レイヤとして特に効果的です。

このストレージ オプションの使用を開始するには、以下のリソースをご覧ください。

ファイル ストレージ

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 と共有できます。

このストレージ オプションの使用を開始するには、以下のリソースをご覧ください。

オブジェクト ストレージ（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 SQL や Spanner などのマネージド データベースは、運用上のオーバーヘッドを削減し、Google Cloud インフラストラクチャ向けに最適化されています。マネージド データベースの保守や運用は、Kubernetes に直接デプロイするデータベースよりも簡単です。

マネージド データベースを使用する理由

Google Cloud マネージド データベースを使用すると、GKE 上のステートフル ワークロードが永続データにアクセスすると同時に、バックアップ、パッチ適用、スケーリングなどのメンテナンス タスクを自動化できます。データベースを作成、アプリを構築し、Google Cloud にスケールを実行させます。ただしこれは、正確なバージョンのデータベース、拡張機能、または目的のデータベースの正確なバージョンにアクセスできない可能性があることも意味します。

GKE では、次のような Google Cloud マネージド データベース サービスとの接続がサポートされています。

このストレージ オプションの使用を開始するには、以下のリソースをご覧ください。

ビルド アーティファクト（Artifact Registry）

Artifact Registry は、ビルドおよびデプロイしたコンテナ イメージ、OS パッケージ、言語パッケージ用のリポジトリ マネージャーです。

Artifact Registry を使用する理由

Artifact Registry は、非公開コンテナ イメージ、Helm チャート、およびその他のビルド アーティファクトの保存に適しています。

Artifact Registry Docker リポジトリから GKE にイメージを pull するには、Artifact Registry ドキュメントの Google Kubernetes Engine へのデプロイをご覧ください。

次のステップ