KubeCon + CloudNativeCon Japan 2025 特集 Blog 最終日の記事になります。

このブログでは、Google の Kaslin Fields 氏が発表した「Multi Cluster Magics with Argo CD and Cluster Inventory」のセッション内容をベースに、マルチクラスタにおけるアプリケーション運用とクラスタ管理の標準化について紹介します。

目次

1. 自己紹介
2. KubeCon の参加に至った経緯
3. マルチクラスタ運用の課題
4. Argo CD でマルチクラスタを管理
5. Glue Code
6. SIG Multicluster の発足
7. Multicluster API と MCO
8. まとめ

自己紹介

Argo CD でマルチクラスタを管理

# application-cluster1.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-cluster1
spec:
  destination:
    server: https://cluster1.example.com
    namespace: myapp
  source:
    repoURL: https://github.com/example-org/myapp
    path: manifests
    targetRevision: main
  project: default
---
# application-cluster2.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-cluster2
spec:
  destination:
    server: https://cluster2.example.com
    namespace: myapp
  source:
    repoURL: https://github.com/example-org/myapp
    path: manifests
    targetRevision: main
  project: default
---
# and more...

しかし、クラスタやアプリケーションの数が増えるにつれて、この構成はスケーラビリティの観点で課題が生じてきます。複数のアプリケーションがそれぞれ異なるクラスタにデプロイされる状況では、どのアプリケーションがどのクラスタリストを参照しているかという構成の依存関係が複雑に絡むためリストのリスト状態となります。

 

Glue Code

• クラスタマネージャ系
  • KubeFleet / Open Cluster Management（OCM）/ Karmada / Clusternet …etc.
• マルチクラスタ対応アプリケーション
  • Argo CD / KubeVela / Istio / Kueue …etc.
• クラウドベンダ
  • GKE Fleet / Azure Kubernetes Fleet Manager …etc.

SIG Multicluster の発足

前述の通り、現在のマルチクラスタ環境にはツールやベンダが乱立・散在し、クラスタリストの形式や扱い方に統一性がありません。このため、ツール間でクラスタ情報を連携する共通言語が存在せず、管理者はプロジェクト毎に同じようなクラスタ情報を定義・管理・同期するといった非効率な作業が必要になる課題があります。

以上の背景を受け、マルチクラスタの標準化に向けて Kubernetes コミュニティの中で SIG Multicluster（Special Interest Group Multicluster）が発足しました。

SIG Multicluster では、マルチクラスタの運用を統一的に扱うために API 標準を 2 つ定義しています。

Part 1：Multicluster Services（MCS）API

MCS は複数クラスタに跨る L4 の Service をシームレスに扱うことを目的とした API です。

• ServiceExport：各クラスタのサービスを外部に公開することを宣言
• ServiceImport：他クラスタから参照するためのインターフェース
• ClusterSet：MCS のスコープとなるクラスタの集合体

これにより、一つのサービスが複数クラスタ上にあることを前提に通信や名前解決ができるようになります。MCS 自体は KEP-1645 として 2020 年に提案され、現在では Istio や Submariner、MCS-aware CoreDNS 等でも採用が進んでいます。

Part 2：ClusterProfiles API

ClusterProfiles は、Cluster Inventory に基づき複数のクラスタのメタデータを、統一された形式で集約・管理することを目的とした API です。Cluster Inventory とは、Kubernetes におけるマルチクラスタ運用をスケーラブルかつ標準化された形で実現するための概念で、ClusterProfiles API 仕様の中心的な考え方になっています。

ClusterProfiles API 自体は 2023 年末頃に KEP-4322 で提案されました。

ClusterProfile は CRD として定義される Kubernetes オブジェクトで、location や environment、kubernetesVersion 等の任意の情報を ラベル・プロパティとして保持します。複数の ClusterProfile をまとめて ClusterSet を構成し、用途別・環境別のグルーピングが可能になり、Namespace 毎にも分離できるため、マルチテナント環境にも対応可能です。

これにより、Argo CD や MultiKueue といったツールが、同じフォーマットのクラスタ情報を参照・制御できるようになります。

Multicluster API と MCO

実際にクラスタマネージャに ClusterProfiles API を採用した例として Google Cloud が 2025 年 4 月に OSS として公開した Multicluster Orchestrator（MCO）があります。MCO は、マルチクラスタ環境をより自律的かつ最適化された形で運用するためのオーケストレータで、以下のような特徴があります。

1. Hub Cluster

Hub Cluster では、全ての ClusterProfile を管理し、ここに CRD を集約します。Hub Cluster は、マルチクラスタ全体の状態・リソースを一元的に管理する言わば Control-Plane の立ち位置で、他のクラスタを管理対象ノードとして扱います。

2. Auto Bin Packing 型スケジューリング

location や environment、kubernetesVersion 等、各クラスタが持つ情報を ClusterProfile 経由で取得します。クラスタ管理者が定義したルールやポリシに従って、最適なクラスタにアプリケーションをデプロイします。

また、負荷状況に応じて、スケジュール先を動的に再調整、Rebalancing することも可能です。

3. 他ツールとの統合性

MCO は単体で完結するわけではなく、既存ツールと連携して機能することを前提に設計されています。例えば、Argo CD ApplicationSet のデプロイ先を ClusterProfile を経由して MCO で決定したり、Kueue の Job や Batch 処理をクラスタ横断でスケジューリングしたりといった活用が可能です。

また、GKE / EKS / AKS といった各クラウドプロバイダが提供する Kubernetes エンジンに ClusterProfile が統合されれば、マルチクラウドにおける統一的なクラスタ運用が可能になるとされています。

まとめ

本ブログでは、Google の Kaslin Fields 氏による「Multi Cluster Magics with Argo CD and Cluster Inventory」のセッションを通して、Kubernetes におけるマルチクラスタ運用の構造的な課題と、その解決に向けた標準化の取り組みについて紹介しました。

Argo CD のような GitOps ツールベースの運用には限界があり、ツールやベンダ毎に異なるクラスタ管理方式が乱立する中、マルチクラスタ管理におけるツール間ギャップの解消と標準化への取り組みとして、Kubernetes SIG Multicluster は発足しました。

従来の管理方針は、主に「どのクラスタに何を置くか」といった静的な指定が中心でしたが、MCO はそれを動的に判断・最適化できるため、運用コストの大幅な削減やリソースの最大活用が期待できます。

現段階ではビジョンの面が強いものの、ClusterProfiles API や MCS API を取り入れた具体的なソリューションも既に登場しつつあります。特に、MCO では Kubernetes そのものの抽象化に焦点を当てており、単なるリソースのデプロイではなく、アプリケーションの配置、通信、キャパシティ管理、モニタリング、再スケジューリングまでを含めた、言わば Fleet as a Platform が目指されています。

セッションを通じて

ABEMA は今や 300 を超えるマイクロサービスで構成されており、非常に多くのクラスタを管理しています。また、テレビのイノベーションをコンセプトに、いつでもどこでも繋がる社会インフラを目指しており、これまで以上に堅牢なインフラ設計と高可用性が求められています。

そのためには複数の Kubernetes エンジン、リージョンに跨るアプリケーションの冗長構成を取る必要があり、今後もマルチクラスタを目指した運用体制はより加速していくと考えられます。

本ブログでも紹介した通り、現在の仕組みではマルチクラスタの管理に関して多くの課題が残ります。このような課題の解消に向けて、今回紹介した SIG Multicluster の仕組みは非常に興味深いものでした。まだまだビジョンの面が多い内容ではありますが、個人的にも今後の動きが非常に気になるところです。

KubeCon + CloudNativeCon Japan 2025 特集 Blog

1. KubeCon + CloudNativeCon Japan 2025 現地参加を最大限に活かす！現役エンジニアが注目するポイントと歩き方
2. KubeCon + CloudNativeCon Japan 2025 1 日目参加速報
3. KubeCon + CloudNativeCon Japan 2025 2 日目参加速報
4. 生成 AI マーケットの不確実性に立ち向かうためのクラウドネイティブ技術
5. 若手だけじゃない！ベテラン層だって活躍したい
6. Cloud Native とサイバーエージェントのこれまでとこれから
7. 2 node で HA 構成を実現する Extended Raft Algorithm 〜入社 2 年目 AJA 所属〜
8. Kubernetes SIG Node に Deep Dive する 〜入社 1 年目 CIU 所属〜
9. Kubernets を活用したインフラ基盤運用の安定化について 〜入社 2 年目 CIU 所属編〜
10. テナント志向で考える、マルチクラスタ・マルチクラウド運用 〜入社 1 年目 ABEMA 所属〜
11. Argo CD x Cluster Inventory で実現するマルチクラスタ運用の新境地 〜入社 2 年目 ABEMA 所属〜 (👈 この記事)