GKE Hypercluster について

多くの GKE ユーザーは、大規模な AI/ML ワークロードを実行しているか、独自のモデルの重みなどの機密性の高い知的財産(IP)を所有しています。このドキュメントでは、複数のリージョンで実行でき、クラスタ内のノードによって管理されるリモート インスタンスでコンテナを実行するインフラストラクチャ アーキテクチャについて説明します。このリンクされたインフラストラクチャ(さまざまなオペレーティング システム(OS)イメージや機能を含む)は、GKE Hypercluster と呼ばれます。

GKE Hypercluster は、GKE または AI Hypercomputer の制限を超えるセキュリティとスケーラビリティを必要とし、その目標を達成するために運用上の摩擦の増加を許容できるお客様を対象としています。

GKE Hypercluster を使用するタイミング

デフォルトでは、GKE クラスタは、特別なセキュリティとスケーラビリティの要件があるワークロードなど、ほとんどの本番環境 AI ワークロードの要件を満たすように設計されています。たとえば、GKE は次のようなユースケースをサポートしています。

  • Confidential Google Kubernetes Engine Node で GPU を実行し、ワークロードから vTPM またはハードウェア ベースの Confidential Computing モジュールにアクセスします。
  • Workload Identity Federation for GKE を使用して、暗号化されたデータへのアクセスを特定の承認済み ID に制限します。
  • ComputeClasses とノードプールの自動作成を使用して、使用可能な容量に基づいて TPU ノードと GPU ノードをデプロイします。
  • アクセス承認、アクセスの透明性、GKE control plane authority を使用して、Google の担当者によるアクセスを制御し、監視します。

GKE Hypercluster のリンクされたインフラストラクチャは、一般的な GKE アーキテクチャの既存の制限を超える機能を必要とする特定のセキュリティとスケーラビリティのユースケース向けに設計されています。設計上、特定の GKE オブザーバビリティ、トラブルシューティング機能、機能は、リンクされたインフラストラクチャでは使用できません。このインフラストラクチャは、次の特殊なユースケースに対応するように、一般的な GKE クラスタ アーキテクチャを変更します。

  • 内部関係者の脅威からモデルとクエリを保護する: 独自のプラットフォーム管理者と Google の担当者による、独自のモデルの重み付けや機密性の高い推論クエリとレスポンスへのアクセスを防ぎます。AI アセットは、証明可能で検証可能な環境でのみ復号されます。

  • リージョン間で AI ワークロードを実行する: サポートされているノードのスケーリング上限を超える規模でワークロードをデプロイします。クラスタのリージョンまたはゾーン以外の場所を含め、使用可能な容量があるリージョンでアクセラレータ インフラストラクチャを作成して使用します。

仕組み

GKE クラスタのアーキテクチャで説明したように、Standard モードのクラスタには、Kubernetes API を提供し、クラスタ内のすべてのノードとノードプールを管理するリージョンまたはゾーンのコントロール プレーンがあります。クラスタ内のすべてのノードは、特定の VPC ネットワークを使用します。このネットワークは、他の Google Cloud リソースでも使用される場合があります。すべての GKE ノードは、kubelet ノード エージェント、ロギング エージェントと指標エージェント、その他の Kubernetes コンポーネントと GKE コンポーネントなど、さまざまなシステム コンポーネントを実行します。

一方、GKE Hypercluster は、Kubernetes API サーバーに Node オブジェクトとして登録されていないリンクされたランナーという名前のインスタンスを使用します。これらのインスタンスには次のプロパティがあります。

  • Kubernetes エージェントがなく、GKE コンポーネントの最小限のセット。
  • ユースケースに基づく特殊な OS イメージ。GKE ノードイメージはありません。
  • インスタンスは、個別の専用 VPC ネットワークを使用します。

リンクされたランナーは、ランナーとクラスタをリンクするクラスタ内のコントロール ノードによって管理されます。コントロール ノードは、kubelet プロセスなどのシステム コンポーネントを実行します。1 つの制御ノードを複数のランナーにリンクできます。これらのリンクされたランナーは、クラスタ リージョンのデータセンターが提供できる以上の電力を必要とするトレーニング ジョブなど、非常に大規模なワークロードを実行するように設計されています。

インフラストラクチャの設定時に、ユースケースに基づいて特定の構成でランナーを作成し、インスタンスをクラスタ内の専用コントロール ノードにリンクします。リンクされたランナー インスタンスには kubelet がなく、API サーバー トラフィックを生成しないため、Kubernetes API はコントロール ノードのみを管理する必要があります。リンクされたランナー インスタンスを作成するときに、次のいずれかの方法でインスタンスを構成できます。

  • デフォルト構成: デフォルトでは、リンクされたインスタンスは Container-Optimized OS イメージを実行する Compute Engine VM です。プラットフォーム管理者や SRE などの緊急対応担当者は、SSH を使用してインスタンスにアクセスできます。これらのインスタンスは、インフラストラクチャへの管理者アクセスを維持する場合に適しています。
  • Sealed 構成: 一部の AI ワークロードは、独自のモデルの重みや暗号化されたクエリなどの機密データを処理します。Google の担当者や独自の管理者を含むすべてのアクセスから AI アセットを保護する必要がある場合は、リンクされたランナー インスタンスをシールドモードで構成できます。これらのシールド インスタンスには、次のプロパティがあります。
    • 最小限の OS イメージを使用する。
    • TPU には Titanium Intelligence エンクレーブを使用し、GPU には NVIDIA Confidential Computing を使用します。
    • ワークロード レベルとファームウェアの構成証明を実行します。
    • コンテナ イメージの署名を検証します。
    • インスタンスとコンテナへのすべての管理者権限を防止します。

使用する構成に関係なく、インスタンスには、GKE 固有の TPU ランタイム パラメータや GKE ロギング エージェントとモニタリング エージェントなど、GKE ノードに含まれるコンポーネントや機能の多くが含まれていません。

デフォルト構成について

デフォルトでは、GKE Hypercluster 用に作成するインスタンスは、本番環境のワークロードを実行するように設計されています。また、トラブルシューティングや緊急対応のために、通常の GKE ノードと同様のメカニズムを備えています。インスタンスは Compute Engine マシンタイプで実行され、Container-Optimized OS イメージを使用します。中断やクラッシュなどのインシデントが発生した場合、管理者はインスタンスに直接アクセスして問題をトラブルシューティングできます。Kubernetes ノードとは異なり、インスタンスは Kubernetes と GKE の機能を有効にするシステム コンポーネントの多くを実行しないため、各インスタンスで割り当て可能なリソースが増えます。

任意の Google Cloud リージョンにインスタンスを作成し、それらのインスタンスをクラスタのコントロール ノードにリンクできます。コントロール ノードは、Kubernetes コントロール プレーンの多くの機能を実行し、デプロイされたワークロードのライフサイクルを管理します。

シールド構成について

主なユースケースが、すべてのアクセスからアセットを保護することである場合は、リンクされたランナーを、シールされた構成を使用するように構成できます。これにより、次のセキュリティ プロパティを持つインスタンスが作成されます。

  • 各インスタンスは、特定のテクノロジーに基づく高信頼実行環境(TEE)です。
  • インスタンスは、Container-Optimized OS に基づく最小限の OS イメージを実行します。このイメージでは、SSH アクセスが無効になり、コンテナ シェル アクセスが防止され、構成証明エージェントが実行されます。
  • インスタンスで実行できるワークロードを正確に指定するポリシーを定義します。たとえば、ワークロードで署名付きコンテナ イメージ ダイジェストを使用することや、特定の Pod 仕様を使用することを要求できます。
  • 認証エージェントは、ファームウェアとワークロードの測定値を Google Cloud Attestation に送信し、検証可能な認証クレーム結果トークンを返します。

結果として得られるインスタンスは、承認されたコードのみが実行でき、機密データがハードウェアベースの安全なエンクレーブで処理される、制限付きの検証済み環境を提供します。インスタンスから返される証明書情報により、ワークロードが承認済みのコードを実行し、正しいインスタンスにデプロイされていることが確認されます。

これらのシールド インスタンスを使用して、暗号化されたモデル、クエリ、レスポンスを次の方法で保護できます。

  • モデルの重み付け:

    1. Cloud KMS の Cloud HSM 鍵を使用してモデルの重みを暗号化する。
    2. 暗号化されたモデルの重みを Cloud Storage に保存します。
    3. 証明されたワークロードにのみバケットへの読み取りアクセス権を付与します。
    4. 証明済みのワークロードにのみ復号鍵へのアクセス権を付与する。
  • クエリと回答:

    1. Cloud KMS の Cloud HSM 鍵を使用して、クエリとレスポンスを暗号化します。
    2. 復号アクセス権を証明されたワークロードにのみ付与します。
    3. ワークロード間で暗号化されたデータを送信するときに、証明書の提示を要求する。

シールド構成は、リンクされたランナー インスタンスのオプションのセキュリティ レイヤです。デフォルト構成と同様に、任意のリージョンとゾーンにシールされたインスタンスを作成できます。ただし、シールされたインスタンスのセキュリティ プロパティにより、管理者と Google の担当者はトラブルシューティングのためにホスト インスタンスにアクセスできません。

利用資格

GKE Hypercluster は、一般的な GKE クラスタのアーキテクチャと機能では対応できない特定の AI/ML ユースケース向けに設計されています。GKE Hypercluster を使用するお客様には、通常とは異なるセキュリティとスケーラビリティの要件があります。GKE Hypercluster は、対象となる GKE のお客様のみが利用できます。利用資格の確認とアクセス権のリクエストについては、専任のアカウント チームにお問い合わせください。