Karmada 是開放的多云多集群容器編排引擎，旨在幫助用戶在多云環境下部署和運維業務應用。憑借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑遷移單集群工作負載，并且仍可保持與 Kubernetes 周邊生態工具鏈協同。

Karmada v1.15 版本現已發布，本版本包含下列新增特性：

• 多模板工作負載的資源精確感知
• 集群級故障遷移功能增強
• 結構化日志
• Karmada 控制器和調度器性能顯著提升

多模板工作負載的資源精確感知

Karmada 利用資源解釋器獲取工作負載的副本數和資源請求，并據此計算工作負載所需資源總量，從而實現資源感知調度，聯邦配額管理等高階能力。這種機制在傳統的單模板工作負載中表現良好。然而，許多AI大數據應用的工作負載 ?CRD（如 FlinkDeployments，PyTorchJob 和 RayJob 等）包含多個 Pod 模板或組件，每個組件都有獨特的資源需求。由于資源解釋器僅能處理單個模板的資源請求，無法準確反映不同模板間的差異，導致多模板工作負載的資源計算不夠精確。

在這個版本中，Karmada 強化了對多模板工作負載的資源感知能力，通過擴展資源解釋器，Karmada 現在可以獲取同一工作負載不同模板的副本數和資源請求，確保數據的精確性。這一改進也為多模板工作負載的聯邦配額管理提供了更加可靠和精細的數據支持。

假設你部署了一個 FlinkDeployment，其資源相關配置如下：

spec:jobManager:replicas:?1resource:cpu:?1memory:?1024mtaskManager:replicas:?1resource:cpu:?2memory:?2048m

通過 ResourceBinding，你可以查看資源解釋器解析出的 FlinkDeployment 各個模板的副本數以及資源請求。

spec:components:- name:?jobmanagerreplicaRequirements:resourceRequest:cpu:?"1"memory:?"1.024"replicas:?1- name:?taskmanagerreplicaRequirements:resourceRequest:cpu:?"2"memory:?"2.048"replicas:?1

此時，FederatedResourceQuota 計算的 FlinkDeployment 占用的資源量為：

?status:overallUsed:cpu:?"3"memory:?3072m

注意：該特性目前處于 Alpha 階段，需要啟用 MultiplePodTemplatesScheduling 特性開關才能使用。

隨著多模板工作負載在云原生環境中的廣泛應用，Karmada 致力于對其提供更強有力的支持。在接下來的版本中，將基于此功能進一步加強對多模板工作負載的調度支持，提供更加細粒度的資源感知調度——敬請期待更多更新！

集群級故障遷移功能增強

在之前的版本中，Karmada 提供了基本的集群級故障遷移能力，能夠通過自定義的故障條件觸發集群級別的應用遷移。為了滿足有狀態應用在集群故障遷移過程中保留其運行狀態的需求，Karmada 在 v1.15 版本支持了集群故障遷移的應用狀態中繼機制。對于大數據處理應用（例如 Flink），利用此能力可以從故障前的 checkpoint 重新啟動，無縫恢復到重啟前的數據處理狀態，從而避免數據重復處理。

社區在?PropagationPolicy/ClusterPropagationPolicy?API 中的?.spec.failover.cluster?下引入了一個新的?StatePreservation?字段， 用于定義有狀態應用在故障遷移期間保留和恢復狀態數據的策略。結合此策略，當應用從一個故障集群遷移到另一個集群時，能夠從原始資源配置中提取關鍵數據。

狀態保留策略?StatePreservation?包含了一系列?StatePreservationRule?配置，通過?JSONPath?來指定需要保留的狀態數據片段，并利用關聯的?AliasLabelName?將數據傳遞到遷移后的集群。

以 Flink 應用為例，在 Flink 應用中，jobID?是一個唯一的標識符，用于區分和管理不同的 Flink 作業（jobs）。當集群發生故障時，Flink 應用可以利用?jobID?來恢復故障前作業的狀態，從故障點處繼續執行。具體的配置和步驟如下：

apiVersion:?policy.karmada.io/v1alpha1
kind:?PropagationPolicy
metadata:name:?foo
spec:#...failover:cluster:purgeMode: DirectlystatePreservation:rules:- aliasLabelName:?application.karmada.io/cluster-failover-jobidjsonPath:?"{ .jobStatus.jobID }"

1. 遷移前，Karmada 控制器將按照用戶配置的路徑提取 job ID。

2. 遷移時，Karmada 控制器將提取的 job ID 以 label 的形式注入到 Flink 應用配置中，比如?application.karmada.io/cluster-failover-jobid : <jobID>。

3. 運行在成員集群的 Kyverno 攔截 Flink 應用創建請求，并根據?jobID? 獲取該 job 的 checkpoint 數據存儲路徑，比如 ?/<shared-path>/<job-namespace>/<jobId>/checkpoints/xxx，然后配置?initialSavepointPath?指示從save point 啟動。

4. Flink 應用根據?initialSavepointPath?下的 checkpoint 數據啟動，從而繼承遷移前保存的最終狀態。

該能力廣泛適用于能夠基于某個 save point 啟動的有狀態應用程序，這些應用均可參考上述流程實現集群級故障遷移的狀態中繼。

注意：該特性目前處于 Alpha 階段，需要啟用 StatefulFailoverInjection 特性開關才能使用。

功能約束：

1. 應用必須限定在單個集群中運行；

2. 遷移清理策略（PurgeMode）限定為?Directly，即需要確保故障應用在舊集群上刪除之后再在新集群中恢復應用，確保數據一致性。

結構化日志

日志是系統運行過程中記錄事件、狀態和行為的關鍵工具，廣泛用于故障排查、性能監控和安全審計。Karmada 組件提供豐富的運行日志，幫助用戶快速定位問題并回溯執行場景。在先前版本中，Karmada 僅支持非結構化的文本日志，難以被高效解析與查詢，限制了其在現代化觀測體系中的集成能力。

Karmada 在 1.15 版本引入了結構化日志支持，可通過?--logging-format=json?啟動參數配置 JSON 格式輸出。結構化日志示例如下：

{"ts":“日志時間戳”,"logger":"cluster_status_controller","level":?"info","msg":"Syncing cluster status","clusterName":"member1"
}

結構化日志的引入顯著提升了日志的可用性與可觀測性：

• 高效集成：可無縫對接 Elastic、Loki、Splunk 等主流日志系統，無需依賴復雜的正則表達式或日志解析器。

• 高效查詢：結構化字段支持快速檢索與分析，顯著提升故障排查效率。

• 可觀察性增強：關鍵上下文信息（如集群名、日志級別）以結構化字段呈現，便于跨組件、跨時間關聯事件，實現精準問題定位。

• 可維護性提升：結構化日志使開發者和運維人員在系統演進過程中更易于維護、解析和調整日志格式，保障日志體系的長期穩定與一致性。

Karmada 控制器和調度器性能顯著提升

在本次版本中，Karmada 性能優化團隊繼續致力于提升 Karmada 關鍵組件的性能，在控制器和調度器方面取得了顯著進展。

控制器方面，通過引入優先級隊列，控制器能夠在重啟或切主后優先響應用戶觸發的資源變更，從而顯著縮短服務重啟和故障切換過程中的停機時間。

測試環境包含 5,000 個 Deployment、2,500 個 Policy 以及 5,000 個 ResourceBinding。在控制器重啟且工作隊列中仍有大量待處理事件的情況下，更新 Deployment 和 Policy。測試結果顯示，控制器能夠立即響應并優先處理這些更新事件，驗證了該優化的有效性。

注意：該特性目前處于 Alpha 階段，需要啟用 ControllerPriorityQueue 特性開關才能使用。

調度器方面，通過減少調度過程中的冗余計算，降低遠程調用請求次數，Karmada 調度器的調度效率得到了顯著提升。

測試記錄了在開啟精確調度組件 karmada-scheduler-estimator 情況下，調度 5,000 個 ResourceBinding 所用的時間，結果如下：

• 調度器吞吐量 QPS 從約 15 提升至約 22，性能提升達 46%；

• gRPC 請求次數從約 10,000 次減少至約 5,000 次，降幅達 50%。

這些測試證明，在 1.15 版本中，Karmada 控制器和調度器的性能得到了極大提升。未來，將繼續對控制器和調度器進行系統性的性能優化。