# **告別混亂！用 Argo CD 與 Cluster API 施展多叢集管理的終極魔法**

> 本文成果承蒙陽明交大「高等教育深耕計畫」113 學年度第 2 學期「職涯學習助學金－校外職訓」計畫支持

各位在雲原生大海中航行的夥伴們！你是否也曾被多叢集（Multi-Cluster）管理的複雜性搞得焦頭爛額？一下要處理 Latency，一下要搞定資料落地（Data Gravity），還要兼顧資安隔離和成本控管。當叢集數量從個位數變成雙位數，甚至更多時，那種混亂的感覺，我們都懂。

在 KubeCon Japan 2025 的一場精彩演講中，來自 Google Cloud 的 Kaslin Fields 為我們揭開了應對這場混亂的神秘面紗。核心思想不再是頭痛醫頭、腳痛醫腳，而是透過 **標準化** 來一勞永逸。

這篇文章將帶你深入剖析這場演講的精華，結合所有簡報、逐字稿的關鍵資訊，從問題的根源、過去無效的嘗試，一路探索到由 Kubernetes SIG Multicluster 推動的革命性解法：**ClusterProfiles API** 與 **Cluster Inventory**。準備好了嗎？讓我們一起來學習如何用標準化的力量，搭配 Argo CD，施展真正優雅的多叢集管理魔法！

## **一、問題的起點：我們想要一個「管理叢集的 Kubernetes」**

從 Kubernetes 誕生的第一天起，大家就有個夢想：我們能不能像 Kubernetes 管理 Pod 和 Deployment 一樣，用同樣聲明式（Declarative）的方式來管理叢集本身？我稱之為「Kubernetes for Kubernetes」的終極理想。

但現實很快就給了我們一巴掌。最大的阻礙是：**Kubernetes 叢集對自己一無所知，更不用說外部世界了。**

一個 Kubernetes 叢集內部，沒有一個標準的欄位叫做 cluster-name 或 cluster-id。它就像一個失憶的作業系統，能管理內部的行程（Workloads），卻不知道自己是哪台電腦。這個根本性的缺陷，讓我們無法輕易地建立一個上層的控制器來統一調度多個叢集。

## **二、初次嘗試：Namespace，隔離了孤單**

社群的第一個解法，是我們現在再熟悉不過的 Namespace。

它的邏輯是：既然無法管理「外部」的叢集，那我們就把一個「內部」的叢集切分成好幾個虛擬的子叢集吧！這個概念類似虛擬機，但在資源層級上更輕量，它隔離的是 Kubernetes 的 API 物件，像是 Deployment、Service 等。


*\ K8s 在單一叢集內提供了邏輯上的隔離。（[圖片來源](https://kubernetes.io/docs/concepts/security/multi-tenancy/)）*

Namespace 是個偉大的發明，也是公認的 Best Practice。但它並未解決大家真正需要多叢集的核心問題：

* **地理位置考量**：為了降低延遲（Latency）或滿足數據主權（Data Gravity），叢集必須部署在不同地區。
* **隔離需求**：基於資安（Security）、成本（Cost）或組織（Organizational）理由，需要以叢集作為硬性的隔離邊界。

Namespace 終究只是在單一叢集內的劃地為王，無法跨越物理和網路的鴻溝。於是，多叢集管理的挑戰依然存在。

## **三、混沌的現狀：Argo CD 與永無止盡的「列表的列表」**

為了解決跨叢集部署的問題，社群和廠商們各自發展出了一套方法論。以當紅的 GitOps 工具 **Argo CD** 為例，一個常見的作法是：

1. 將目標叢集的連線資訊（Kubeconfig）儲存在 Kubernetes Secret 中。
2. Argo CD 讀取這些 Secret，形成一份「目標叢集列表」。
3. 當要部署應用時，Argo CD 就會遍歷這份列表，將 Manifests 推送到每一個目標叢集。

*\ Argo CD 透過 Cluster Secrets 來管理多個目標叢集。*（[圖片來源](https://kccncjpn2025.sched.com/event/1x71F/multi-cluster-magics-with-argo-cd-and-cluster-inventory-or-dont-get-lost-in-the-clusterverse-navig-kaslin-fields-google)）

聽起來很美好，對吧？但當你的組織規模擴大時，惡夢就開始了：

* **應用 A** 可能需要部署到 1、2、3 號叢集。
* **應用 B** 可能只需要部署到 2、3 號叢集。
* **應用 C** 需要部署到 3、4、5 號叢集。

很快地，你會為每個應用或每組應用維護一份獨立的「叢集列表 Secret」。Argo CD 變成了一個**消費多份叢集列表**的工具。為了管理這些不同的列表，你可能需要再寫一個工具或腳本... 這就陷入了一個遞迴的困境：**我們需要一個管理器，來管理管理叢集列表的管理器。**

這個問題並非 Argo CD 獨有。放眼整個雲原生生態系，我們看到的是一場混亂的軍備競賽：

* **專注於多叢集的開源專案**：KubeFleet, Open Cluster Management (OCM), Karmada, Kubestellar...
* **內建多叢集模式的專案**：Kueue, Istio, KubeVela...
* **雲端供應商的解決方案**：GKE Fleet, Azure Kubernetes Fleet Manager...

大家都在做同一件事：**重新發明一次輪子，打造自己的叢集列表和管理方式。** 這讓人不禁想起那張經典的 XKCD 漫畫：

當你有 14 個競爭的標準時，再創造一個「通用」標準的結果，就是你有 15 個競爭的標準。

我們需要的不是第 15 個標準，而是一個釜底抽薪的、來自 Kubernetes 核心的根本性解決方案。

## **四、標準化的曙光：SIG Multicluster 的兩大神器**

終於，魔法師登場了！他們就是 Kubernetes 的 **SIG Multicluster**（多叢集特殊興趣小組）。他們沒有創造第 15 個標準，而是回到了問題的本質，打造了兩套標準化的 API，讓 Kubernetes 終於能夠「認識世界」。

### **神器一：Multicluster Services (MCS) API (KEP-1645)**

這是在 2020 年提出的較早的 API，主要解決「服務發現」的問題。它定義了三個核心物件：

* ServiceExport：將一個叢集內的 Service 標記為可供外部存取。
* ServiceImport：在另一個叢集內，自動建立一個代理（Proxy），指向被 Export 的遠端 Service。
* ClusterSet：一個邏輯上的概念，用來定義一組「互相信任」的叢集。在同一個 ClusterSet 內的叢集，其服務可以互相通訊。

MCS API 讓跨叢集服務呼叫變得像在單一叢集內一樣簡單，但它主要處理的是 Data Plane 的網路流量，對於 Control Plane 的叢集管理，還差臨門一腳。

### **神器二：ClusterProfiles API (KEP-4322)**

這是 2023 年才提出的、真正改變遊戲規則的 API。它提供了一種標準化的方式來**描述一個 Kubernetes 叢集**。

核心是一個名為 ClusterProfile 的 CRD (Custom Resource Definition)。它是一個 Kubernetes 物件，用來存放一個叢集的各種元數據（Metadata）和屬性。

一個 ClusterProfile 的 YAML 看起來可能像這樣：

apiVersion: multicluster.x-k8s.io/v1alpha1  
kind: ClusterProfile  
metadata:  
  name: gke-prod-us-west1  
  namespace: fleet-system \# 這個物件本身也存在於某個 Namespace  
spec:  
  \# ...  
  clusterManager:  
    name: gke-fleet-manager  
  properties:  
    \- name: "clusterset.k8s.io"  
      value: "prod-fleet"  
    \- name: "location"  
      value: "us-west1"  
    \- name: "has-gpu"  
      value: "true"  
    \- name: "cost-center"  
      value: "project-alpha"  
status:  
  version:  
    kubernetes: 1.28.3  
  \# ...

看到了嗎？透過 ClusterProfile，我們終於有了一個標準的、API-driven 的方式來回答這些問題：

* 這個叢集在哪個地區？(location: us-west1)
* 它屬於哪個叢集集合？(clusterset.k8s.io: prod-fleet)
* 它有 GPU 資源嗎？(has-gpu: true)
* 它的成本中心是誰？(cost-center: project-alpha)

## **五、終極魔法：Hub Cluster 與 Cluster Inventory 架構**

有了 ClusterProfile 這個強大的武器，一個全新的多叢集管理架構應運而生——**Hub and Spoke** 模型。

1. **Hub Cluster**：我們指定一個 Kubernetes 叢集作為「管理中心」（也稱為 Management Cluster 或 Admin Cluster）。所有 ClusterProfile 的 CRD 物件都會存放在這個 Hub Cluster 上。
2. **Cluster Inventory**：Hub Cluster 上所有 ClusterProfile 物件的集合，就構成了一份權威的、即時的、可查詢的「**叢集清單 (Cluster Inventory)**」。這不再是一份儲存在 Secret 裡的靜態列表，而是一個活生生的、可透過 kubectl 或控制器操作的 API 資源。
3. **Producers & Consumers**：
* **Producers (生產者)**：負責自動建立和更新 ClusterProfile 物件。例如，GKE 或 AKS 的控制器可以作為 Producer，當你建立一個新叢集時，它會自動在 Hub Cluster 上註冊一個對應的 ClusterProfile。
* **Consumers (消費者)**：讀取和使用這份 Cluster Inventory 的工具。**Argo CD** 在這個新架構下，就從一個「列表管理者」轉變為一個「列表消費者」。它不再需要維護自己的 Secret 列表，而是直接 watch Hub Cluster 上的 ClusterProfile 物件，根據標籤（labels）來決定要將應用程式部署到哪些叢集。

整個架構如下圖所示：

\+-------------------------------------------------------------+  
|                       Hub Cluster                           |  
|                                                             |  
|   \+----------------+      \+----------------+                |  
|   | ClusterProfile |      | ClusterProfile |                |  
|   | gke-prod-usw1  |      | aks-stage-eun  | .... (Inventory)  
|   | labels:        |      | labels:        |                |  
|   |  env: prod     |      |  env: stage    |                |  
|   |  gpu: true     |      |  gpu: false    |                |  
|   \+----------------+      \+----------------+                |  
|         ^                        ^                          |  
|         |                        | (API Watch)              |  
\+---------|------------------------|--------------------------+  
          | (Auto-created by)      |  
          |                        |  
\+---------+------+         \+-------+--------+  
| Argo CD        |         | MCO Controller | (Consumers)  
\+----------------+         \+----------------+

這個架構的優雅之處在於，它將**叢集註冊**（Producers 的職責）和**叢集消費**（Consumers 的職責）徹底解耦。Argo CD 只需專注於 GitOps 同步，而 MCO (Multicluster Orchestrator，Google 的一個開源實現) 可以專注於更複雜的工作負載調度，例如基於叢集容量和自定義指標的智慧化 Bin-packing。

## **六、實戰與迷思澄清 (來自 Q\&A 的洞見)**

在演講後的問答環節，也釐清了許多重要的觀念：

* **叢集 Autoscaling vs. Workload Autoscaling**：這套機制主要解決的是在「現有」叢集上調度 Workload 的問題。它**不會**自動增減叢集的數量。叢集的生命週期管理（建立/刪除），仍然需要外部工具（如 Terraform 或雲端供應商的控制器）來完成，這些外部工具可以扮演 ClusterProfile Producer 的角色。
* **不會有「一個 API 統治一切」**：SIG Multicluster 的策略是循序漸進、逐個擊破。他們先用 MCS API 解決服務發現，再用 ClusterProfiles API 解決叢集描述，未來可能還會有其他 API。目標是提供一組可組合的、可擴展的基礎元件。
* **廠商實作的必要性**：為什麼不直接由社群提供一個通用的多叢集管理器？因為很多功能（如網路、負載均衡、容量計算）都與底層基礎設施（GCP, AWS, Azure）緊密相關。因此，最好的模式就是「**社群定義標準，廠商實現細節**」。這確保了標準的統一性，同時又能發揮各平台的最大效能。
* **Data Plane 和滾動升級**：目前這套標準主要聚焦在 Control Plane。Data Plane 的網路連通性（如 Multi-Cluster Gateway）和跨叢集的平滑滾動升級（Rolling Upgrades），在目前的實作中仍需手動規劃或依賴廠商的特定解決方案，這塊還有很大的發展空間。

## **結論：未來已來，只是分佈不均**

多叢集管理的混亂時代正在過去。感謝 SIG Multicluster 的努力，我們正從過去那種各自為政、不斷重複發明輪子的窘境，走向一個基於開放標準、統一 API 的新時代。

ClusterProfile 和 Cluster Inventory 的概念，將叢集從一個個不透明的黑盒子，變成了可被程式化管理的 API 物件。這為 Argo CD 這類的 GitOps 工具、以及更智慧的調度器（如 MCO）打開了無限的可能性。

雖然這套標準還很新（KEP-4322 在 2023 年提出），離完美的無縫體驗也還有一段路要走，但方向已經無比清晰。這不僅僅是一次技術升級，更是一次思維模式的轉變——從管理「列表」，到管理「資源」。

### **Call to Action**

如果你對這個主題感興趣，想參與或了解更多，可以從以下地方開始：

* **閱讀官方文件**：[SIG Multicluster Concepts](https://multicluster.sigs.k8s.io/concepts/cluster-profile-api/)
* **加入 Slack 討論**：在 Kubernetes Slack 中加入 \#sig-multicluster 頻道，或在 CNCF Slack 中加入 \#argo-cd 頻道。
* **探索開源專案**：研究 Google 的 [Multi-Cluster Orchestrator](https://github.com/GoogleCloudPlatform/gke-fleet-management/tree/main/multi-cluster-orchestrator) 專案，了解標準的具體實現。

希望這篇文章能幫助你理解多叢集管理的未來樣貌。讓我們一起擁抱標準，告別混亂，施展屬於我們自己的雲原生魔法吧！