TrueFoundryによるマルチクラウドGPUオーケストレーション：ハイパースケーラーと専門クラウドのためのリファレンスアーキテクチャ

現在、AIチームにとってGPU容量は最も厳しい制約の一つです。プロビジョニングは Amazon EC2 P5インスタンス や Azure ND H100 v5シリーズVMでは、クォータ制限、リージョン容量の制約、または吸収が困難な商用コミットメントに直面する可能性があります。そのため、専門のGPUクラウド（ CoreWeave、 Lambda、 Fluidstack、その他いくつかのプロバイダー）は、単なるオーバーフロー容量ではなく、実行可能な本番環境のターゲットとなっています。これらのプロバイダーはそれぞれ、GPUワークロード向けにマネージドKubernetesパスを提供しています。 CoreWeave Kubernetes Service (CKS)、 Lambda Managed Kubernetes (MK8s) を1-Click Clusterで、そして Fluidstack managed Kubernetes。

これらのプロバイダーとハイパースケーラーのフットプリントを並行して運用すると、実際の運用上の複雑さが増します。ダッシュボード、IDシステム、可観測性、デプロイフローがそれぞれ異なります。TrueFoundryの役割は、これらのKubernetesクラスターをそれぞれ単一のコントロールプレーンに接続し、1つのUIでデプロイターゲットとして提示し、各プロバイダーが既に提供しているクラスターネイティブな自動化を置き換えることなく、その上に一貫したK8s運用レイヤーを提供することです。

この記事では、それが実際にどのようなものかについて説明します。アーキテクチャ、クラスターの接続に必要なもの、プラットフォームの自動化がどこで終わり、プロバイダーの自動化がどこから始まるのか、そして推奨される実践的なパターンです。

アーキテクチャ：1つのコントロールプレーン、多数のコンピュートプレーン

TrueFoundryは分割プレーンアーキテクチャを採用しています。その コントロールプレーン （TrueFoundryが管理するもの、またはセルフホスト型）は、メタデータ、RBAC、デプロイメントマニフェスト、UIを保持します。 コンピュートプレーン は、お客様自身のKubernetesクラスターです。複数のコンピュートプレーンを単一のコントロールプレーンに接続できます。つまり、EKSクラスター、AKSクラスター、CKSクラスター、MK8sクラスター、FluidstackマネージドK8sクラスターのすべてが、同じダッシュボードにレポートできるということです。

各クラスターで tfy-agent が実行され、コントロールプレーンへのセキュアなアウトバウンドWebSocketを開きます。エージェントはクラスターの状態をストリーミングし、エージェントプロキシは、クラスターにインバウンドエンドポイントを必要とせずに、そのアウトバウンド接続を介してコントロールプレーンがKubernetesの変更を適用できるようにします。ワークロード、データプレーンのトラフィック、プロバイダーの認証情報は、各クラスターのクラウドアカウント内に留まり、トラフィックはコントロールプレーンを介してコンピュートプレーン間を流れることはありません。これらは独立したIDを持つ独立したクラウドとして機能します。

「クラスターのアタッチ」に実際に必要なもの

エージェントのインストール自体は単一のHelmコマンドですが、それは実際の前提条件があるセットアップの最終段階で行われます。どのクラスター（ハイパースケーラーまたは特殊なもの）でもクリーンにアタッチするには、クラスターは以下を必要とします。

• Kubernetes 1.28+ 想定されるワークロードプロファイルに応じて、おおよそ250ノード/4,096ポッドのヘッドルームを持つ
• アウトバウンドエグレス TrueFoundryがプルするコンテナレジストリへの: public.ecr.aws、 quay.io、 ghcr.io, tfy.jfrog.io, docker.io/natsio, nvcr.io, registry.k8s.io
• ワイルドカードドメイン （例： *.lambda-pool.example.com）およびTLS証明書 — cert-manager + Let's Encryptが推奨されるパターンです
• 動作するロードバランサーまたはイングレスパス。 マネージドハイパースケールK8sは通常、クラウドロードバランサーとの統合を通じてこれを提供します。ベアメタルまたは特殊なクラスターでは、プロバイダーがサポートするイングレスおよびIP割り当てパスを確認してください。
• 永続ストレージのサポート ボリュームおよびアーティファクト用で、通常、プロバイダーのCSI対応ブロック、ファイルシステム、またはオブジェクトストレージ統合を通じて提供されます
• 到達可能なコンテナレジストリおよびアーティファクトストア イメージのプル、ビルド出力、およびワークフローアーティファクト用
• ノードラベル 汎用/特殊クラスターの場合： truefoundry.com/nodepool=<pool-name> すべてのノードに、そして truefoundry.com/gpu_type=<GPU_TYPE> GPUノードに（TrueFoundryはEKS/GKE/AKS上のノードプールのみを自動検出します）

マネージドハイパースケールK8sでは、TrueFoundryのOpenTofu/Terraformモジュールがそのほとんどをカバーします。特殊なクラウドでは、プロバイダーのマネージドK8sサービスを直接使用します — コンソールからプロビジョニングし、前提条件を準備してからアタッチします。正確なエージェントインストールコマンドは、プラットフォームUIで Attach Existing Clusterをクリックすると生成されます。通常、以下の形式になります。

helm repo add truefoundry https://truefoundry.github.io/infra-charts/
helm upgrade --install tfy-agent truefoundry/tfy-agent \
  --set tenantName=my-org \
  --set clusterName=lambda-h100-pool \
  --set controlPlaneURL=https://<YOUR_CONTROL_PLANE> \
  --set clusterTokenSecret=<YOUR_CLUSTER_TOKEN_SECRET>

特殊なクラウド固有の事項：アドオンの重複問題

これは、多くのアーキテクチャに関する投稿が見過ごしがちな点です。前述の特殊なクラウドは、TrueFoundryのデフォルトアドオンスタックの一部と重複するKubernetesコンポーネントをすでに提供しています。両者が同じコンポーネントをインストールすると、ダッシュボードの重複からサポートされていないGPUオペレーターのデプロイまで、さまざまな競合が発生する可能性があります。

CoreWeaveはこの点について明言しています。 CoreWeaveはCKSクラスター上でNVIDIA GPU Operatorを管理しており、二重インストールしないよう警告しています。プラットフォームが管理するデプロイメントのみがサポートされています。CKSクラスターをアタッチする際は、TrueFoundryのGPU Operatorアドオンを無効にしてください。

具体的には：

• CoreWeave CKS 最近のクラスターではCoreWeaveが管理するNVIDIA GPU Operator、Ciliumネットワーキング、ストレージ統合、DPUベースのインフラストラクチャ、およびCoreWeaveのオブザーバビリティが含まれます。アタッチする際は、TrueFoundryの GPU Operator アドオンを無効にし、オブザーバビリティの重複がないか確認してください。
• Lambda MK8s GPUおよびInfiniBand/RDMAサポート、 lambda-shared StorageClassを介した共有永続ストレージ、NVIDIA DCGM Grafanaダッシュボード、および自動ノード修復機能を提供します。TrueFoundryの GPU Operator LambdaがすでにGPUの有効化を管理している場合はアドオン。プロバイダーのDCGMダッシュボードはTrueFoundryのオブザーバビリティとは別個のものであり、それと並行して実行できます。
• Fluidstack マネージドKubernetes GPU OperatorとNetwork Operator、バッチスケジューリング用のRay、Volcano、Kueue、Atlasマネージドストレージ、およびクラスターヘルスオブザーバビリティのサポートを謳っています。TrueFoundryの GPU Operator プロバイダーがすでにそれを管理している場合はアドオン。プロバイダーのバッチスケジューリングスタックは、ワークフローオーケストレーションの代替ではなく、補完的なものです。

「 Attach Existing Cluster 」フォームには Cluster Addons セクションがあり、プロバイダーがすでに提供しているアドオンをオフに切り替えることができます。これはクラスターごとに一度限りの決定です。

TrueFoundryがクラスター全体に追加するもの

クラスターがアタッチされると、プラットフォームはプロバイダーが提供するK8sの上に一貫した運用エクスペリエンスを提供します。

• すべてのクラスターに1つのUI。 すべてのデプロイメント、すべてのジョブ、すべてのサービス、すべてのワークスペースが、同じダッシュボードでアタッチされたすべてのクラスターにわたって表示されます。
• 一貫したデプロイメントマニフェスト形式。 サービスまたはジョブを一度作成し、 cluster_name フィールドを変更することで別のクラスターをターゲットにできます。ただし、宛先クラスターの前提条件が一致する場合に限ります（一致するGPUタイプ、レジストリアクセス、シークレット、ストレージクラス）。
• ArgoCD経由でのGitOpsバージョン管理されたデリバリー 各クラスターにデプロイされ、GitOpsが有効な場合はデプロイ設定がGitに保存されます。
• クラスターごとの可観測性Control Plane UIにPrometheusベースのメトリクスが表示され、より詳細なクラスターレベルのダッシュボードにはオプションでGrafanaを利用できます。(注: これは統合された運用上の可視性であり、フェデレーションされた長期メトリクスバックエンドの代替ではありません。)
• 各クラスターでのArgo Workflows バッチジョブやトレーニング実行向けに、実行履歴とステップレベルの可観測性が一貫して表示されます。
• 各クラスター内のサービス向けオートスケーリングリクエストレートベースのスケーリング、時間ベースのルール、キューベースのパターン、および適切なワークロードに対するスケール・トゥ・ゼロを含みます。
• クラスター内でのキャパシティタイプ配置ワークロードは、基盤となるクラウドおよびノードプロビジョニング設定がそれをサポートしている場合、スポット、オンデマンド、またはオンデマンドフォールバック付きスポットのキャパシティをターゲットにできます。
• ワークスペースベースのRBACとSSO プラットフォーム層で、ワークロードがどのクラスターで実行されるかに関わらず、一貫した権限モデルを提供します。

TrueFoundryができること 未対応の機能 (現時点では)

範囲を明確にするために — これらは顧客が求める実際の機能ですが、現時点ではプラットフォーム機能ではありません。

• クラスター間スケジューリング。 ジョブをデプロイする際、特定のクラスターをターゲットにします。プラットフォームは、最も安価なクラスターを自動的に選択したり、リアルタイムのキャパシティに基づいてルーティングしたり、実行中のワークロードをクラスター間で再バランスしたりしません。
• クラスター間フェイルオーバー。 Lambda 1CCでハードウェアの問題が発生したり、CoreWeaveリージョンでキャパシティが不足したりした場合でも、プラットフォームはEKS予約でジョブを自動的に再試行しません。基盤となるクラスターがサポートしている場合、クラスター内配置とフォールバックポリシーは役立ちますが、クラスター間フェイルオーバーは別の問題であり、提供されていません。
• 集約型GPUキャパシティプーリング。 CoreWeave、Lambda、AWS上のH100キャパシティは、1つのプールされたクォータとしてではなく、3つの独立したクラスターとして追跡されます。UIには3つすべてが表示され、スケジューラはそれぞれを独立したものとして扱います。
• コストを考慮した自動ルーティング。 リアルタイムのプロバイダー価格に基づいてジョブを実行する場所を選択する機能は、現在のところプラットフォームにはありません。

ユースケースが真にクラスター間のオーケストレーションを必要とする場合（例えば、最も安価な利用可能なクラウドにバーストすべきトレーニングジョブなど）、その決定はTrueFoundryのクラスターごとのデプロイAPIの上に、オーケストレーション層（CI/CDロジック、小規模なカスタムスケジューラ、またはArgo WorkflowsやTemporalのようなワークフローツール）で構築してください。プラットフォームはクラスター間で一貫したデプロイプリミティブを提供しますが、ルーティングの決定はユーザーに委ねられます。

実際のワークフロー：Lambda 1-Click Clusterのアタッチ

期待が正しく設定されるよう、具体的な手順を以下に示します。

1. Lambdaで1-Click Clusterをプロビジョニングします マネージドKubernetesを有効にします。サイズ（16から2,000以上のGPU）と予約期間を選択します。
2. クラスター管理者アクセスを取得します Lambdaの認証フローを介して、以下を確認します。 `kubectl get nodes` でGPUワーカーが `Ready`と表示されることを確認します。
3. クラスター内で前提条件を準備します。 ワイルドカードDNSとイングレスパスを設定し、TLS証明書の自動化をインストールまたは確認し、 `lambda-shared` StorageClassが共有ストレージに必要な場合に存在すること、およびTrueFoundryが必要とするコンテナレジストリへのエグレスを確認します。
4. TrueFoundryで「Attach Existing Cluster」をクリックします クラスターの詳細を入力します。 GPU Operatorアドオンを無効にする LambdaがすでにGPU有効化を提供している場合。
5. 生成されたhelmコマンドを実行します クラスター内で。エージェントと選択したアドオンが起動するまで待ちます。通常、前提条件が整ってから5～10分かかります。
6. 許容設定を構成する このクラスターを対象とするTrueFoundryワークスペースで。MK8sノードには許容する必要があるGPUテイントがあります。ワークスペースレベルの許容設定は、そのクラスターに送信されるすべてのジョブに適用されます。
7. 確認する クラスターが接続済みと表示されることを確認し、本番ワークロードを移行する前に、小さなテストジョブ（シングルGPU vLLMサービスまたは1ノードのトレーニング実行）をデプロイしてください。

準備されたクラスターでの合計時間は通常30～60分で、主にDNS伝播、証明書発行、およびhelmインストールに時間がかかります。

実践的な比較

まとめ

マルチクラウドGPU戦略は現実のものであり、AIロードマップにおいて計算能力が制約となるにつれて、ますます実用的になっています。実用的なアプローチは、EKS、AKS、GKE、CKS、MK8s、FluidstackマネージドKubernetesのいずれであっても、各クラスターを標準的なKubernetesアタッチメントとして扱い、プラットフォームがその上に一貫した運用レイヤーを提供することです。

得られるもの：接続したすべてのクラスターにわたる単一のUI、クラウドに関わらず一貫したデプロイメントとGitOpsパターン、マニフェストレベルでのワークロードのポータビリティ（前提条件が一致する場合）、顧客のクラウドアカウント間での完全なデータ分離。現時点では得られないもの：自動的なクラスター間スケジューリング、キャパシティプーリング、コストを考慮したルーティング。これらの決定は、プラットフォームのクラスターごとのデプロイAPIの上に構築され、ユーザー自身が行うことになります。

このスタックを評価している場合、自然な出発点は、2つのクラスター（1つはハイパースケーラー、もう1つは専門的なもの）を接続し、スケールアウトする前に、それぞれのクラスターで代表的なジョブを実行して運用上のエルゴノミクスを検証することです。

‍