Karmada 在 2026 年 9 月的 KubeCon + CloudNativeCon + OpenInfra Summit 上海站宣布升上 CNCF 最高等級的 Graduated tier，同一週發出 v1.19。CNCF 畢業這件事不只是一張認證，它代表這個專案的治理、成熟度、生產環境案例已經被基金會用一整套審查標準敲過，社群裡另一支同期的 Open Cluster Management 到現在還卡在 Sandbox，Karmada 一路衝到頂端這件事在多叢集 Kubernetes 這個領域算是決定性的分水嶺。
多叢集這條路過去五年一直是 Kubernetes 生態最尷尬的段落：K8s 本身只管一個叢集，跨叢集的分派、故障轉移、資源同步全靠外部工具接。臺灣有 AWS Tokyo、GCP Taiwan、Azure Taiwan north 三個公有雲區域，加上機房代管跟自架 K8s，中大型企業往往同時管四五個叢集，資源要怎麼放、掛掉怎麼倒手一直沒有乾淨解。Karmada 走的路是把「叢集」變成 Kubernetes 的排程對象，讓 kube-scheduler 那套 nodeSelector、affinity、taint/toleration 的直覺延伸到叢集這一層。
為什麼 Kubernetes 生態需要一個新的排程層
Kubernetes API server 對 pod 的排程有整套完備語意——nodeSelector 挑節點、affinity 定拓撲、priorityClass 決優先權——但這一切都停在單一叢集的邊界。要跨叢集分派工作負載，社群前幾年的解法是靠 GitOps：Argo CD ApplicationSet 用一份範本擴出 N 個 Application、每個對應一個叢集，Flux Kustomization 也是類似路數。這條路能跑，但排程邏輯完全是宣告式配置的靜態展開，做不到「叢集 A 掛了自動切到 B」「按剩餘 GPU 數動態分配 replicas」這種真正的排程行為。
Karmada 選的路是自己起一個獨立的 control plane：它跑自己的 etcd 跟 API server，然後透過 Cluster Controller 把成員叢集當成排程資源。這個決定的成本很直接——多一套 stateful 系統要維護，備援跟升級都要另外規劃。回報則是可以真正做到動態排程，Karmada Scheduler 拿到的資訊包括每個叢集的可用 CPU、記憶體、GPU、Kubernetes 版本、開啟的 add-on，能算出即時可用容量再決定 replicas 怎麼切。
PropagationPolicy 的 Duplicated 跟 Divided 到底差在哪
PropagationPolicy 是 Karmada 最核心的 CRD，決定一個工作負載要被複製到哪些叢集、怎麼複製。這裡有兩個關鍵選項——Duplicated 跟 Divided，選錯會直接影響資源帳單跟可用性設計。
Duplicated 是把整份 replicas 完整複製到每個候選叢集。deployment 宣告 6 顆 pod、選中 3 個叢集，結果是 18 顆 pod 分佈成 6+6+6。這適合的是靜態部署：控制平面元件、監控 agent、log collector，這類服務本來就要在每個叢集各跑一份完整實例。
Divided 是把 replicas 切開分配。6 顆 pod 可以變成 2+2+2、4+1+1，或按可用容量動態調整。這裡又分三種切法：Aggregated 盡量集中到少數叢集，讓小服務不要平白多起幾個叢集付管理成本；Weighted Static 按管理員定義的權重靜態分配，適合有明確 SLA 差異的環境；Weighted Dynamic 才是真正的排程行為——Karmada 定期拉每個叢集的 available capacity，按剩餘資源比例動態調配。
實務上，跑 stateless web 服務適合 Divided Dynamic，跑 stateful 或需要每叢集一份的服務走 Duplicated。混合走法也很常見：主服務用 Divided、DaemonSet 類元件用 Duplicated，同一個 PropagationPolicy 群組管理。
v1.19 把 priority scheduling 跟 AI 訓練場景收進 Beta
v1.19 這一版最有份量的改動是 priority-based scheduling 從 alpha 升到 Beta，而且預設開啟。這件事延續兩年的 issue 跟社群討論，核心是想解決「兩個工作負載都想搶同一組叢集資源，誰該退讓」這個經典排程問題。以前 Karmada 對這種衝突的處理很粗糙——先到先得，後來的要嘛等、要嘛去排容量比較差的叢集。v1.19 之後可以宣告 priority，高優先順序的搶到適合的叢集，低優先順序的動態退到次選。
另一條大改是多元件排程能力，直接針對 AI 訓練工作負載。分散式訓練典型的部署形態是 PyTorchJob 或 MPIJob，一個工作負載內部同時有 master、worker、parameter server 這幾種 pod，過去 Karmada 只能把整個 job 塞進單一叢集。v1.19 之後這幾種 pod 可以被視為一個排程群組跨叢集分派，配合 GPU 資源查詢跟親和性設定，能讓大型訓練工作跨機房拉伸。這對臺灣有 GPU 資源分散在幾個機房的組織來說是實務可用的能力。
KubeFleet 跟 Open Cluster Management 為什麼走不同路線
多叢集這個賽道還有兩個候選：KubeFleet（Azure Kubernetes Fleet Manager 的上游）跟 Open Cluster Management（Red Hat ACM 的上游）。兩者都在 CNCF Sandbox。這三個專案的分野不是「哪個功能多」，是設計哲學上的分岔。
KubeFleet 的核心賣點是 agent-based pull model——中央 hub 不主動連成員叢集，成員叢集主動 pull 設定。這條路特別適合邊緣運算：只能出去不能進來的叢集也能被納管。缺點是排程能力相對薄弱，主打的是設定同步跟 rollout 控制。Karmada 兩種模式都支援，但排程能力遠比 KubeFleet 深。
OCM 走的是治理優先的路線。它強調 hub-and-spoke 拓撲、細粒度的存取控制、多租戶模型，比較適合像 telco 這種需要嚴格分權跟稽核的場景。動態排程能力沒有 Karmada 那麼強。
實務決策的邏輯應該這樣拆：如果目標是把工作負載按資源分派、跨區故障轉移、GPU 這類稀缺資源要動態排程，Karmada 是目前唯一畢業級別的選擇。如果只需要把幾份設定同步到一批邊緣叢集、不需要動態排程，KubeFleet 反而更輕。要嚴格治理跟稽核優先，OCM 加上 Red Hat 的商業支援才是完整方案。
部署 Karmada 前該想清楚的取捨
Karmada 不是零成本方案。多一套 control plane 意味著多一份 etcd 要備援、多一組 API server 要監控、多一條升級路徑要規劃。實務上會建議把 Karmada control plane 跑在跟工作負載完全獨立的一個管理叢集裡——那個叢集本身可以很小，兩三顆節點就夠，但務必要有獨立的備份策略。
再者是 CRD 學習曲線。PropagationPolicy、OverridePolicy、ClusterOverridePolicy、ResourceBinding、Work 這幾個 CRD 都要團隊搞清楚才能推得動；而且它們的行為跟原本單叢集的 Deployment 直覺有落差，特別是 OverridePolicy 這種「同一份 manifest 在不同叢集有不同值」的機制，除錯時要看兩層 diff（原始 manifest 對 OverridePolicy、OverridePolicy 對實際部署）。
網路面也要注意。成員叢集跟 Karmada control plane 之間要有穩定的雙向連線（push 模式）或穩定出向（pull 模式）。跨區部署的話，這條連線的延遲跟頻寬直接影響排程反應速度跟 secret 同步時效。走臺灣本地機房加上多雲環境的架構，通常會用專線或 VPN 拉一條低延遲的管理網。
結論
Karmada 升上 CNCF Graduated 這件事把多叢集 Kubernetes 的技術債清單縮短了一大截。工作負載排程、故障轉移、跨區資源分派這幾個過去要拼湊 GitOps 加自訂 controller 才能做到的能力，現在都能在一個宣告式 API 底下完成。臺灣的中大型組織有機房、有多雲、有 GPU 分散在幾個地點的實務環境，這個時間點導入 Karmada 是相對合理的判斷。
NCSE Network 的 VPS 產品線適合作為 Karmada 成員叢集或管理叢集的部署基礎，臺灣是方電訊機房的 Intel Gold CPU 加 NVMe SSD 能提供穩定的 etcd IO，配合彈性的 IP Transit 頻寬支援跨區同步。想在臺灣本地建置或延伸多叢集架構的團隊，歡迎到 https://ncse.tw 了解 VPS 跟網路服務的相關方案。
