Kubernetes API を使用して GKE で Cloud Storage オブジェクトを使用する - パート 1
Google Cloud Japan Team
※この投稿は米国時間 2024 年 2 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。
Filesystem in Userspace（FUSE）は、ファイル システムを Linux カーネルにエクスポートするために使用されるインターフェースです。Cloud Storage FUSE を使用すると、Cloud Storage バケットをファイル システムとしてマウントできます。これにより、アプリケーションはクラウド固有の API を使用せずに、一般的なファイル IO オペレーション（オープン、読み取り、書き込みなど）を使用してバケット内のオブジェクトにアクセスできます。Cloud Storage FUSE は一般提供されています。
Google Kubernetes Engine (GKE) は、Cloud Storage FUSE CSI ドライバを使用することで Cloud Storage FUSE とすぐに統合できます。CSI ドライバを使用すると、Kubernetes API を使用して既存の Cloud Storage バケットを永続ボリュームとして使用できます。アプリケーションでは、Cloud Storage FUSE ファイル システム セマンティクスを使用して、オブジェクトのアップロードとダウンロードを行うことができます。Cloud Storage FUSE CSI ドライバは、オープンソースの Google Cloud Storage FUSE CSI ドライバを利用したフルマネージドのエクスペリエンスを提供します。ポータビリティ、信頼性、パフォーマンスが向上し、すぐに GKE と統合できます。
データ ポータビリティで AI ワークロードを強化する
Cloud Storage は、ほぼ無制限のスケール、シンプルさ、経済性、パフォーマンスという点から AI / ML ワークロードによく使用されています。とはいえ、AI / ML フレームワークの中には、ネイティブのオブジェクト ストレージ API を直接サポートするライブラリを使用するものもあれば、ファイル システム セマンティクスを必要とするものもあります。さらに言えば、環境全体にわたって一貫性のあるエクスペリエンスを確保するために、ファイル システム セマンティクスを標準化することが望ましいとされています。Cloud Storage FUSE CSI ドライバを使用すれば、GKE ワークロードは Kubernetes API を使用してローカル ファイル システムとしてマウントされた Cloud Storage バケットにアクセスでき、さまざまな環境間でデータ ポータビリティが実現します。
以下に、GKE 上の Job ワークロードで一般的なファイル システム セマンティクスを使用して Cloud Storage オブジェクトにアクセスする方法を示します。
以下のリンク先では、CSI ドライバを使用して Cloud Storage バケットのオブジェクトを使用する AI / ML ワークロードの例をさらにご覧いただけます。
Cloud Storage FUSE CSI ドライバを使用すれば、Cloud Storage バケットとサービス アカウントを指定するだけで、残りは GKE が処理します。続いては、より詳細な管理方法と基礎となる設計について詳しく見ていきましょう。
簡単なことは簡単なままに、困難なことを可能に
Cloud Storage バケットは、Pod の仕様でインラインの CSI エフェメラル ボリュームを使用することで簡単に指定できます。別途 PersistentVolume（PV）オブジェクトや PersistentVolumeClaim（PVC）オブジェクトを維持する必要はありません。互換性や認証の要件から従来の PV / PVC のアプローチが好ましい場合も、CSI ドライバは標準的な静的プロビジョニング アプローチに対応します。このアプローチは、ReadWriteMany アクセスモードによって、複数のアプリケーションが単一の PV / PVC を使用してデータを使用できるようにします。
CSI ドライバは、Pod の仕様にサイドカー コンテナを自動で追加します。そのため、ユーザーはアプリケーション コードに注力でき、Cloud Storage FUSE ランタイムの管理について心配する必要がありません。さらに、不要になったサイドカー コンテナは自動で終了するよう設計されています。これにより、サイドカー コンテナによって Kubernetes Job ワークロードの終了がブロックされることを防げます。
サイドカー コンテナが追加されると、ほとんどの軽量ワークロードで適切に機能するデフォルトのリソース割り当てとマウント オプションが設定されます。また、Cloud Storage FUSE ランタイムのマウント オプションとリソース割り当てのファインチューニングも柔軟に行えます。
厳しい制約の克服が革新的な設計につながる
Kubernetes で FUSE ドライバを実行するにはいくつかの制約があり、これらは導入の妨げになりかねません。Google は、カーネルのクロスプロセス ファイル ディスクリプタ転送機能を利用して権限、認証、ワークロードのライフサイクル、リソースの使用量を明確に分離することで、これらの制約を克服する、サイドカー ベースの新しいソリューションを開発しました。
従来の FUSE CSI ドライバは、CSI ドライバ コンテナ内のすべての FUSE インスタンスを実行するので、単一障害点が生じます。ノードの基盤となる仮想マシン（VM）上で FUSE インスタンスが直接実行される場合もありますが、その場合は予約済みのシステム リソースが消費される可能性があります。GKE のソリューションは異なります。Cloud Storage FUSE は、ワークロード コンテナと並行して、サイドカー コンテナ内で実行されます。この Pod 単位のモデルによって、Cloud Storage FUSE のライフサイクルをワークロードのライフサイクルに関連付けます。Cloud Storage FUSE はワークロードの一部として実行されるので、Workload Identity を使用して認証することができます。すなわち、サービス アカウントの認証情報を手動で管理する必要がなく、Pod レベルのきめ細かな IAM アクセス制御を使用できるということです。さらに、Cloud Storage FUSE が使用するリソースは Pod によって処理されるので、パフォーマンスをファインチューニングすることが可能になります。
FUSE ドライバをサイドカー コンテナで実行するうえでのもう一つの大きな課題に、FUSE ランタイムに高度なコンテナ権限が必要なことが挙げられます。この制約により、GKE Autopilot ではサイドカーに基づいたソリューションがほぼ不可能となります。なぜなら、Autopilot クラスタでは特権コンテナが許可されないからです。GKE のソリューションは、権限がなくても FUSE サイドカー コンテナを実行できる 2 段階の FUSE マウント テクニックを導入しており、特権コンテナにする必要があるのは CSI ドライバ コンテナのみとなります。以下の図に、2 段階の FUSE マウント プロセスの仕組みを示します。
- 段階 1: CSI ドライバがノード VM で「/dev/fuse」デバイスを開き、ファイル ディスクリプタを取得します。その後、そのファイル ディスクリプタを使用して Linux コマンド mount.fuse3 を呼び出し、マウント ポイントを作成します。最終的に、CSI ドライバは Linux の sendmsg コマンドを呼び出し、emptyDir の Unix Domain Socket（UDS）経由でファイル ディスクリプタをサイドカー コンテナに送信します。
- 段階 2: サイドカー コンテナで、ランチャー プロセスが UDS に接続し、Linux の recvmsg コマンドを呼び出してファイル ディスクリプタを受信します。その後、受信したファイル ディスクリプタを使用して FUSE インスタンスを起動し、FUSE マウント ポイントを提供します。
まとめ
Cloud Storage FUSE CSI ドライバは、Kubernetes API を使用してアプリケーションの既存の Cloud Storage バケットを使用できるようにする GKE のフルマネージド ソリューションです。サイドカーをベースとする革新的な設計により、特権や認証、リソース割り当て、FUSE ライフサイクル管理に関する問題を解決します。詳細については、GKE のドキュメント「Cloud Storage FUSE CSI ドライバを使用して Cloud Storage バケットにアクセスする」をご覧ください。また、GitHub リポジトリで問題を送信してください。
-ソフトウェア エンジニア Jiaxun Song
