Zenn
🧭

Next'25 速報 - GKE Multi-cluster Orchestrator 登場！フリート全体で効率的なワークロード配置を実現

に公開
Kubernetes
Google Cloud
GKE
Google Cloud Next
next25
tech

はじめに

現在ラスベガスで開催されている Google Cloud の旗艦イベント「Google Cloud Next'25（以下、Next'25）」に現地参加中の kazz / 岸本 / Shanks / 小堀内です。

Google Cloud Next'25 で発表された 最新情報 を現地からお届けしています。

本記事では、Next'25 のセッション「Build an inferencing platform on GKE with Argo CD and fleets」で発表された、Multi-cluster Orchestrator の特徴や機能について紹介します。

Multi-cluster Orchestrator の特徴

1
事前定義した優先順位やポリシーに基づいて、ワークロードに最適なデプロイ先クラスタを推奨します。

  • マネージドサービス: ユーザーがインフラを管理する必要のない Google Cloud のマネージドサービスとして提供されます (Public Preview 近日開始予定)。
  • CD ツール連携: Argo CD や Flux などの主要な CD ツールと連携します。Multi-cluster Orchestrator は推奨を行うだけで、実際のデプロイは連携した CD ツールが実行します。Argo CD 用には専用のプラグインである ApplicationSet ジェネレータが提供されます。
  • 高度なスケーリングパターン: キャパシティに基づいた動的な配置推奨により、「スケールフロムワン」（既存クラスタが満杯の場合、別のクラスタへスケールアウト）や「スケールフロムゼロ」（必要になるまでデプロイせず、要求発生時に初めてデプロイ）といったスケーリングでコストを最適化してくれます。
  • Fleet / ClusterProfiles 連携: GKE Fleet を基盤とし、オープンソース仕様の ClusterProfile CRD を介してフリート内のクラスタを認識・管理します。GKE 環境では ClusterProfile は自動生成されます。

Multi-cluster Orchestrator の仕組みと役割

2

キャパシティ評価

Multi-cluster Orchestrator は、バックグラウンドで GKE Fleet 内の各クラスタのリソース状況（特に利用可能な CPU, メモリ, アクセラレータなど）を継続的に監視し、評価します。

Multi Kubernetes Cluster Placement CRD (配置ルールの定義)

ユーザーは、ワークロードごとに MultiKubernetesClusterPlacement という CRD を使って、デプロイ先の選定ルールを定義します。この CRD で、対象とするワークロード、デプロイしたいクラスタのリージョン、ラベル、優先順位、最低限必要なクラスタ数などを指定します。

Multi Kubernetes Cluster Placement CRD の定義例

yaml
apiVersion: orchestrator.cluster.gke.io/v1alpha1
kind: MultiKubernetesClusterPlacement
metadata:
  name: inference-workload-placement
  namespace: default
spec:
  workload: # 対象ワークロードを指定
    name: inference-deployment
    kind: Deployment # HPAなども指定可能
    namespace: inference-ns
  rules:
    priorities: # クラスタ選択の優先順位リスト
    - name: us-west1-priority # 優先度 1
      clusterSelector:
        matchLabels:
          topology.kubernetes.io/region: us-west1
      preference: Required # 必須 or Preferred
    - name: us-central1-fallback # 優先度 2
      clusterSelector:
        matchLabels:
          topology.kubernetes.io/region: us-central1
      preference: Preferred
  policy:
    minCapacity: # 最低限配置するクラスタ数
      clusters: 1

配置推奨

MultiKubernetesClusterPlacement で定義されたルールと、リアルタイムの評価結果から、ワークロードをデプロイすべきクラスタのリストが CRD の status フィールドに書き込まれます。

Argo CD 連携

Argo CD は、Multi-cluster Orchestrator 用に提供されるプラグインを通じて MultiKubernetesClusterPlacement CRD の status を監視します。status にリストされたクラスタに対応する Argo CD Application が自動的に生成・更新・削除され、実際のワークロードデプロイが実行されます。

セッションで行われた Multi-cluster Orchestrator のデモ概要

セッションでは、Argo CD 連携デモが行われました。以下のシナリオを想定したデモが行われました。

  1. 通常時: Multi-cluster Orchestrator は MultiKubernetesClusterPlacement のルールに基づき、us-west1 クラスタのみを推奨。Argo CD は us-west1 にのみ推論ワークロードをデプロイ。us-central1 にはデプロイされず、リソースは消費されない。

  2. 負荷増加時: Locust による負荷テストで us-west1 の HPA がトリガーされるが、意図的な制約によりスケールアップできない。Multi-cluster Orchestrator は us-west1 のキャパシティ不足を検知。
    Multi-cluster Orchestrator による再評価と推奨: Multi-cluster Orchestrator は次に優先度の高い us-central1 のキャパシティを評価し、利用可能と判断。status を更新し、us-west1 と us-central1 の両方を推奨。

  3. Argo CD による自動デプロイ: Argo CD の Multi-cluster Orchestrator ジェネレータが status の変更を検知し、us-central1 用の Application を自動生成。ワークロードが us-central1 にもデプロイされ、負荷分散が開始される（スケールフロムワンの実現）。

  4. 負荷減少時: 負荷テスト終了後、us-central1 のワークロードへのリクエストが停止。一定時間（クールダウン期間）後、Multi-cluster Orchestrator は us-central1 が不要と判断し、推奨リストから削除。

  5. Argo CD による自動削除: Argo CD は status の変更を検知し、us-central1 用の Application を自動削除。不要になったリソースが解放され、コストが最適化される（スケールフロムゼロへの回帰）。

Multi-cluster Orchestrator と GKE Fleet の関係

Multi-cluster Orchestrator は単体で動作するのではなく、複数の GKE クラスタを論理的にグループ化し、一元的に管理する GKE Fleet の上で動作します。具体的には、以下の Fleet の機能を活用します。

Cluster Profiles

Multi-cluster Orchestrator がフリート内のクラスタを認識するための標準的な方法を提供します。これはクラスタへのポインタを定義するオープンソース仕様に基づいた CRD であり、GKE Fleet 環境では、フリートメンバーシップに基づいて Google が自動的に生成・管理します。これにより、ユーザーはクラスタ情報を手動で Multi-cluster Orchestrator に登録する必要がありません。

Custom Compute Classes, DWS

これらは、個々のクラスタ内でのリソース効率を高める機能です。Multi-cluster Orchestrator と組み合わせることで、フリート全体での最適化（Multi-cluster Orchestrator）と、各クラスタ内での最適化（Custom Compute Classes など）の両方を実現できます。例えば、Multi-cluster Orchestrator がデプロイ先として推奨したクラスタ内で、さらに Custom Compute Classes を使ってコスト効率の良いノードタイプ（スポット VM など）を優先的に利用させるといった連携が考えられます。

AI 基盤 x Multi-cluster Orchestrator

3
セッションでは AI/ML ワークロード、特に GPU を多用する AI 基盤において Multi-cluster Orchestrator が活用された事例が紹介されました。

GPU を Multi-cluster Orchestrator が状況を見ながら動的に配置することでコストを大幅に削減し、急な負荷増加に対しては、フリート内でキャパシティに余裕のあるクラスタへ迅速にワークロードを拡張したとのことです。また、トレーニングや開発、推論など、異なる目的で利用されるGPUリソースを、Multi-cluster Orchestratorがフリート全体の状況を見て効率的に割り当てることで、リソース共有の効率化に成功したと発表されました。

おわりに

Multi-cluster Orchestrator で、GKE Fleet 上でのマルチクラスタ・ワークロード管理をより効率的にすることができるようになりそうです。

特に、AI/ML ワークロード、大規模なマルチクラスタ環境においては、大きな効果が期待できそうです。

Multi-cluster Orchestrator は現在 Public Preview に向けて準備中であり、今後の機能拡張や対応ツールの拡充が大いに期待されます。マルチクラスタ運用に課題を感じている方は、ぜひ実際に試してみてください。

Discussion