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 に制限します。
  • ComputeClass とノードプールの自動作成を使用して、使用可能な容量に基づいて 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 configuration（密閉構成）: 一部の AI ワークロードは、独自のモデルの重みや暗号化されたクエリなどのセンシティブ データを処理します。Google の担当者や独自の管理者を含むすべてのアクセスから AI アセットを保護する必要がある場合は、リンクされたランナー インスタンスをシールドモードで構成できます。これらのシールド インスタンスには次のプロパティがあります。
    • 最小限の OS イメージを使用します。
    • TPU には Titanium Intelligence エンクレーブを使用し、GPU には NVIDIA Confidential Computing を使用します。
    • ワークロード レベルとファームウェアの構成証明を実行します。
    • コンテナ イメージの署名を検証します。
    • インスタンスとコンテナへのすべての管理アクセスを防止します。

使用する構成に関係なく、インスタンスには、GKE ノードに含まれるコンポーネントや機能（GKE 固有の TPU ランタイム パラメータや 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 のお客様のみが利用できます。利用資格の確認とアクセス権のリクエストについては、専任の Google アカウント担当者にお問い合わせください。