k8s官方宣稱 支持最大150000個pods，5000個node。但是現實生產環境中業務時常有超過該規模的述求，比如說大型電商如淘寶，拼多多，又比如AI和大數據處理的workflow。同時出於合作和業務述求，壹家公司還有可能將業務部署到不同的雲廠商，或者自建機房和公有雲配合使用。因此k8s多集群方案也是雲原生領域的壹個熱點。
目前主要的多集群問題有：
Karmada是基於 kubefed v2 進行修改的壹個項目，因此裏面很多概念都是取自kubefed v2
。
接下來我們會通過官方的demo來體驗壹下使用。
PropagationPolicy 和 OverridePolicy 都是從kubefed v2繼承的概念：
這裏直接用官方樣例對Karmada的 PropagationPolicy 和 OverridePolicy 進行介紹。
首先我們在global集群中部署壹個nginx的應用 Deployment ：
我們想要將這個deployment分發到 cluster1 和 cluster2 兩個工作集群中，那麽我們需要創建壹個 PropagationPolicy 來聲明 Deployment 的分發規則：
上面這個 PropagationPolicy 通過spec中的 resourceSelectors 聲明作用的對象為nginx的 Deployment ，而 placement 指明分發規則為分發到 cluster1 和 cluster2 。因此調度結果如下所示，在 cluser1 和 cluster2 兩個工作集群中都會創建這個nginx的Deployment:
沒有OverridePolicy，則worker集群中的deployment和global的deployment的spec相同，但是我們有可能是要針對worker集群的不同或者業務需求修改內容。
比如現在我們修改cluster1中的deployment的image為 nginx:test ，用來做壹個灰度發布。則我們可以創建壹個如下的 OverridePolicy ：
則新的部署結果如下圖：
通過閱讀Karmada的源碼後，整理了整個的對象處理流程如下圖所示
通過對Karmada的文檔和源碼分析，Karmada相對於kubefed v2的最大優點： 完全兼容k8s的API 。
應用從單集群擴展為多集群時，不需要修改源文件，僅需要添加多集群的manifest包括PropagationPolicy和OverridePolicy，這些文件完全可以由運維同學來添加。因此用戶遷移和學習成本不大。
但是Karmada也有壹些缺點：
Karmada出發點是想讓用戶盡量不要修改原始的物料，來完成單集群到多集群的修改。但是本文也指出了Karmada的壹些缺點(也是感謝評論區的指正)。同時社區也有壹個競品方案 https://open-cluster-management.io/ ，但是整體開發進度沒有karmada快，過段時間也會專門對比壹下。