Karmada 是開放的多雲多集羣容器編排引擎，旨在幫助用户在多雲環境下部署和運維業務應用。憑藉兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑遷移單集羣工作負載，並且仍可保持與 Kubernetes 周邊生態工具鏈協同。
Karmada v1.16 版本現已發佈，本版本包含下列新增特性：
- 支持多模板工作負載調度
- 使用 Webster 算法增強副本分配
- 驅逐隊列速率限制
- 持續的性能優化
支持多模板工作負載調度
當前許多AI/大數據應用由多個組件構成，這些組件之間相互協作以完成複雜的計算任務。例如：
- FlinkDeployment 包含 JobManager 和 TaskManager；
- SparkApplication 包含 Driver 和 Executor；
- RayCluster 包含 Head 和 Worker 節點。
在 Karmada v1.16.0 中引入了多模板調度，這是一項全新的能力，使得 Karmada 能夠將由多個相互關聯組件組成的多模版工作負載完整且統一地調度到具有充足資源的單個成員集羣中。
此功能建立在 v1.15 版本引入的多模板工作負載資源精確感知功能之上，該支持使 Karmada 能夠準確理解複雜工作負載的資源拓撲。在 v1.16 中，調度器利用這些信息來：
-
基於 ResourceQuota 限制來估算成員集羣可以容納的完整的多模板工作負載數；
-
利用成員集羣中實際節點的可用資源來預測工作負載的可調度性。
當前版本為以下多模板工作負載類型提供了內置的資源解釋器：
- FlinkDeployment (flink.apache.org\v1beta1)
- SparkApplication (sparkoperator.k8s.io\v1beta2)
- Job (batch.volcano.sh\v1alpha1)
- MPIJob (kubeflow.org\v2beta1)
- RayCluster (ray.io/v1)
- RayJob (ray.io/v1)
- TFJob (kubeflow.org\v1)
- PyTorchJob (kubeflow.org\v1)
如果使用的是其他的自定義多模板工作負載，也可以通過擴展 Karmada 的資源解釋器來支持它們。
示例，假設你有一個 FlinkDeployment，其資源配置如下：
apiVersion: flink.apache.org/v1beta1
kind: FlinkDeployment
metadata:
name: flink-example
spec:
jobManager:
replicas: 1
resource:
cpu: 1
memory: "1024m"
taskManager:
replicas: 2
resource:
cpu: 2
memory: "2048m
啓用多模板調度功能後，Karmada 會：
- 通過資源解釋器準確解析出 JobManager 和 TaskManager 的資源需求；
- 評估每個成員集羣是否有足夠資源容納完整的 FlinkDeployment（1 個 JobManager + 2 個 TaskManager）；
- 將整個 FlinkDeployment 調度到單個滿足條件的集羣。
此功能的發佈標誌着 Karmada 在支持AI/大數據應用方面邁出了重要一步——將精準的資源解釋、配額感知計算和跨集羣調度融合在一個統一的框架中。
使用 Webster 算法增強副本分配
Karmada 支持多種副本調度策略，如 DynamicWeight、Aggregated 和 StaticWeight，用於在成員集羣之間分配工作負載的副本。這些策略的核心在於將集羣權重轉化為實際副本數量的算法。
在之前的版本中，副本分配算法存在一定的侷限性：
- 非單調性：當總副本數增加時，某些集羣可能意外地獲得更少的副本；
- 缺乏強冪等性：相同的輸入可能產生不同的輸出；
- 不公平的餘數分配：在具有相同權重的集羣之間分配剩餘副本時缺乏合理的優先級策略。
在當前版本中，引入了 Webster 方法（也稱為 Sainte-Laguë 方法）來改進跨集羣調度期間的副本分配。通過採用 Webster 算法，Karmada 現在實現了：
- 單調副本分配：增加總副本數絕不會導致任何集羣丟失副本，確保行為一致且直觀。
- 剩餘副本的公平處理：在權重相等的集羣間分配副本時，優先考慮當前副本數較少的集羣。這種“小優先”方式有助於促進均衡部署，更好地滿足高可用性（HA）需求。
此次更新增強了跨集羣工作負載分配的穩定性、公平性和可預測性，使多集羣環境中的副本調度更加穩健。
驅逐隊列速率限制
在多集羣環境中，當集羣發生故障時，資源需要從故障集羣中驅逐並重新調度到健康的集羣。如果多個集羣同時或在短時間內相繼發生故障，大量的驅逐和重新調度操作可能會使健康集羣和控制平面不堪重負，進而導致級聯故障。
此版本引入了具有速率限制功能的驅逐隊列，用於 Karmada 污點管理器。驅逐隊列通過可配置的固定速率參數來控制資源驅逐速率，從而增強故障遷移機制。該實現還提供了用於監控驅逐過程的指標，提高了整體系統的可觀測性。
這個特性在以下場景特別有用：
- 需要在大規模故障期間防止級聯故障，確保系統不會因為過多的驅逐操作而不堪重負。
- 希望根據不同環境的特性配置驅逐行為。例如，在生產環境中使用較低的驅逐速率，在開發或測試環境中使用較高的速率。
- 需要監控驅逐隊列的性能，包括待處理驅逐的數量、處理延遲以及成功/失敗率，以便調整配置和響應運維問題。
驅逐隊列的核心特性包括：
- 可配置的固定速率限制：通過 --eviction-rate 命令行參數配置每秒驅逐速率。示例：設置每 2 秒最多驅逐 1 個資源：--eviction-rate=0.5。
- 完善的指標支持：提供隊列深度、資源類型、處理延遲、成功/失敗率等指標，便於監控和故障排查。
通過引入速率限制機制，管理員可以更好地控制集羣故障遷移期間的資源調度速率，在保障服務穩定性的同時，提升資源調度的靈活性和效率。
持續的性能優化
在此版本中，性能優化團隊繼續增強 Karmada 的性能，對控制器進行了重大改進。
在 release-1.15 中，引入了 controller-runtime 優先級隊列，它允許基於 controller-runtime 構建的控制器在重啓或主從切換後優先處理最新的變更，從而顯著減少服務重啓和故障轉移期間的停機時間。
在 release-1.16 中擴展了這一能力。對於不是基於 controller-runtime 構建的控制器（如 detector controller），通過為所有使用異步 worker 的控制器啓用優先級隊列功能，使它們也能享受到這一優化。
測試環境包括 5,000 個 Deployments 及其 PropagationPolicy，並在 karmada-controller-manager 組件中啓用了 ControllerPriorityQueue 特性開關。在 karmada-controller-manager 組件重啓後、工作隊列中仍有大量待處理事件的情況下，手動修改一個 Deployment，其更新事件仍能被控制器快速處理並被同步到成員集羣。
這些測試結果證明，Karmada 控制器的性能在 v1.16 中得到了很大的提升。未來，將繼續對控制器和調度器進行系統性的性能優化。
