KamajiとHAMiを用いたマルチテナントGPU共有のシミュレーション

プラットフォームエンジニアは、GPUワークロードを管理する際、リソース効率性とテナント間の分離性の間で難しいトレードオフに直面することがよくあります。Anish Bistaによる最近の実演では、KamajiとHAMiを組み合わせることで、物理的なGPUを安全に共有しつつ、明確に区別されたコントロールプレーンを維持できることを示しています。このアプローチでは、高価なインフラストラクチャへの投資前にアーキテクチャを検証するために、シミュレーションハードウェアを使用しています。

何が起きたか

この記事では、Dockerコンテナを使用して単一のLinuxホスト上に構築された再現可能なラボ環境について詳しく説明しています。目標は、2つのオープンソースプロジェクトであるKamajiとHAMiが連携し、マルチテナントKubernetesクラスタにおけるGPUの低利用率という問題を解決できることを証明することでした。従来、メモリのごく一部しか必要としないPodにフルGPUカードを割り当てると、大きな無駄が生じます。逆に、複数のチームでクラスタを共有すると、分離性が弱まり、セキュリティリスクが高まる傾向があります。

Bistaは、Kamajiをホストするためにkind（Docker上のKubernetes）を使用して管理クラスタを構築しました。この管理層内では、2つの独立したテナント用コントロールプレーンがPodとして作成されました。各テナントには、それぞれ独自のワーカーノードが付与され、これもコンテナとして実行され、ネットワークに参加してHAMiコンポーネントを実行しました。セットアップには2つのシミュレーションテナントが含まれており、tenant-aには1枚のシミュレーションNVIDIA A100、tenant-bには2枚のシミュレーションNVIDIA L4カードが割り当てられました。このラボは8つのテストに合格し、各テナントが他のテナントのリソースやPodを見ずに、フラクショナルなGPUワークロードをスケジュールできることが確認されました。

仕組み

Kamajiは、各テナントのKubernetes APIサーバーとetcdデータストアを中央の管理クラスタ内のPodとして実行することで、コントロールプレーンのオーバーヘッドに対処します。これにより、すべてのチームに対して専用のコントロールプレーンマシンを用意する必要がなくなります。一方、HAMiはスケジューリングおよびデバイスレベルで動作します。Podが特定のGPUスライス（メガバイト単位のメモリと計算パーセンテージで定義）を要求できるようにし、カード全体を占有するのではなく、異なるアプリケーションからの複数のPodが単一の物理GPU上で共存できるようにします。

重要な統合ポイントは、テナントのAPIサーバーとHAMiウェブフック間の通信パスです。APIサーバーは管理クラスタ内で実行されますが、ウェブフックはテナントのワーカーノード上に存在するため、接続はKonnectivityトンネルを経由する必要があります。ラボでは、このリバースプロキシメカニズムが正しく動作し、APIサーバーがスケジューリング判断のためにテナント環境へコールバックできることが確認されました。物理ハードウェアなしでこれをテストするために、著者はHAMiのモックデバイスプラグインを使用しました。これはドライバとのやり取りをスキップし、ノードアノテーションを通じて偽のGPU容量を登録します。

主要な詳細

• ラボは、4 CPUコア、8 GB RAM、20 GBディスクスペースを備えた単一ホストで実行されました。
• tenant-aには1枚のシミュレーション80 GB NVIDIA A100が、tenant-bには2枚のシミュレーション24 GB NVIDIA L4カードが設定されました。
• kindでのIPv6ネットワーク設定によりMetalLBプールが失敗し、ゲートウェイ設定を修正するためにIPv4サブネットの手動検査が必要になりました。
• モックGPU Podは、モックプラグインが割り当て後にロックを自動的に解放しないため、ノードロック競合により当初失敗しました。
• モック環境においてデバイスプラグインの完了ステップをシミュレートするために、Podとノードの手動アノテーションが必要でした。
• このセットアップは配線とスケジューリングロジックを実証しますが、実際のメモリ制限やCUDAパフォーマンスは検証しません。

なぜ重要か

ソフトウェア開発者やプラットフォームエンジニアにとって、このアーキテクチャはGPUインスタンスに関連するクラウドコストを大幅に削減するための道を提供します。フラクショナル割り当てを可能にすることで、組織はより少ないカードでより多くのワークロードを詰め込み、分離されたコントロールプレーンのセキュリティメリットを犠牲にすることなく利用率を向上させることができます。シミュレーションハードウェアを使用してこのスタック全体をテストできる機能により、チームは高価なGPUノードを購入する前に、プラットフォーム設計とCI/CDパイプラインを検証できます。

さらに、KamajiとHAMiの成功した統合は、複雑なマルチテナント要件が必ずしもカスタムのグルーコードや独自ソリューションを必要としないことを示しています。Konnectivityなどの標準的なトンネルの使用により、コントロールプレーンは分散ワーカーノードを安全に管理できます。このモジュール性により、チームはこれらのツールを段階的に採用でき、シミュレーションから始まり、基盤となるスケジューリングメカニズムに対する確信を持って本番ハードウェアへ移行することができます。

実施できること

• kindとKamajiを使用してラボ環境を複製し、ローカルハードウェア上でマルチテナントコントロールプレーンの分離性をテストしてください。
• HAMiのモックデバイスプラグインを使用し、物理的なNVIDIA GPUなしでスケジューリングポリシーとクォータロジックを検証してください。
• kindクラスタでMetalLBに関連するIPv6の問題が発生した場合、Dockerネットワークサブネットを手動で検査してください。
• 開発中にモックプラグインの制限を回避するために、テスト環境で手動のロック解放手順を実装してください。
• 管理クラスタのAPIサーバーとテナントワーカーのウェブフック間のKonnectivityトンネル接続を確認してください。
• モックセットアップは実際のメモリまたは計算制限を強制しないため、実デバイスプラグインの統合を早期に計画してください。