解説: KEP-5313 PlacementDecision API

PlacementDecisionとは

マルチクラスタ環境では「どのクラスタにワークロードを配置するか」という判断（Placement）が必要になります。これまで各ベンダー／スケジューラが独自のAPIを公開していたため、Argo CDのようなGitOpsエンジンやジョブスケジューラは、それぞれ異なるAPIに対応せざるを得ませんでした。

KEP-5313: PlacementDecision API は、この「スケジューラが出す配置結果」を標準化するCRDです。PlacementDecisionは「どのClusterProfileに配置するか」のリストを表現し、任意のスケジューラが生成し、任意のコンシューマ（Argo CDやWork APIを利用するコントローラなど）がそれを参照できます。これにより、スケジューラとコンシューマ間の疎結合が実現されます。

注意: このKEPは現時点ではPR段階であり、まだマージされていませんが、とても活発です。

1. PlacementDecision の YAML 例

apiVersion: multicluster.x-k8s.io/v1alpha1
kind: PlacementDecision
metadata:
  name: app-placement-decision-0
  namespace: argocd
schedulerName: multicluster-placement-controller
decisions:
  - clusterProfileRef:
      apiVersion: multicluster.x-k8s.io/v1alpha1
      kind: ClusterProfile
      namespace: fleet1
      name: cluster1
    reason: "GPUs available"
  - clusterProfileRef:
      apiVersion: multicluster.x-k8s.io/v1alpha1
      kind: ClusterProfile
      namespace: fleet1
      name: cluster2
    reason: "GPUs available"

このように PlacementDecision は「クラスターのリスト」を返すリソースです。

2. Consumer(Argo CD等) がPlacementDecisionを見つける方法とPlacementDecisionの使い方

PlacementRequest（KEPの範囲外であり、各ベンダー依存）等を発行すると、スケジューラは対応する PlacementDecision を生成します。Argo CD のようなコンシューマは以下の方法でそれを発見できます。

• ラベルセレクタ方式

  • スケジューラがスライスに multicluster.x-k8s.io/decision-key=<key> を付与。
  • 必要に応じて multicluster.x-k8s.io/decision-index で並べ替え可能。
  • Argo CD コントローラは labelSelector でまとめて取得できます。

• 決定的な命名方式

  • <base>-<slice-index> のように予測可能な命名規則で作成。
  • Consumer は名前のプレフィックスで一覧化。

さらに、Argo CD の対象ワークロードには multicluster.x-k8s.io/placement-key を付与しておき、コントローラがそれを使って PlacementDecision と突き合わせ、ApplicationSet の対象クラスタ群を動的に更新することができます。つまり、 .decisions[].clusterProfileRef の全クラスタへ1つずつApplicationが作成される様な動作となります。

3. なぜ PlacementDecision は複数（スライス）に分割されるのか

PlacementDecision は 最大100クラスタまでしか1オブジェクトに含められません。これは Kubernetes の etcd のオブジェクトサイズ制約 を考慮した設計です。
例えば 300 クラスタを選定した場合、スケジューラは3つの PlacementDecision スライスを生成し、それらを decision-key や命名規則で関連付けます。
この設計は EndpointSlice と同じ思想で、1オブジェクトの肥大化によるAPIサーバやetcdへの負荷を避け、大規模環境でも安定的に扱えるようにしています。

4. 利用シナリオ

• GPU-aware AI training
  GPU可用性やコストを評価して最適クラスタを選び PlacementDecision に反映。GitOps/Work API がその決定に従ってジョブを展開。GPU不足やコスト変化に応じて再スケジューリング可能。

• Progressive rollout
  最初は一部のカナリクラスタを PlacementDecision に列挙し、ヘルスを見ながら徐々に対象を拡大。コンシューマは決定通りにロールアウトを進められる。

• Disaster recovery
  プライマリクラスタの障害を検知すると、PlacementDecision から対象を外し、スタンバイクラスタを追加。コンシューマは自動的にワークロードを移動。

• Self produce & self consume（例: Argo CD）
  Argo CD のジェネレータが PlacementDecision を生成し、Argo CD コントローラがそれを消費して Application を各クラスタに作成。内部的にも役割分離が可能。

• Multiple consumers fan-out
  1つの PlacementDecision を複数のコンシューマ（GitOps、DR、オーケストレータ等）が同時に利用し、配置結果の一貫性を担保。

まとめ

KEP-5313 が定義する PlacementDecision API は「スケジューラが出した配置結果を標準フォーマットで公開するためのCRD」です。
Argo CD のようなコンシューマは metadata.labels や metadata.name の命名規則を通じて PlacementDecision を発見し、それに基づいてワークロードを自動展開できます。

参考資料

• Kubernetes SIG Multicluster Meeting 2025 09 09 (AMER time)
• KEP-5313: Placement Decision API for multicluster scheduling