動態

詳情 返回 返回

Karmada v1.15 版本發佈!多模板工作負載資源感知能力增強 - 動態 詳情

本文分享自華為雲社區《Karmada v1.15 版本發佈!多模板工作負載資源感知能力增強》,作者:雲容器大未來。

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

Karmada v1.15版本現已發佈,本版本包含下列新增特性:

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

● 集羣級故障遷移功能增強 

● 結構化日誌

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

新特性概覽

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

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

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

假設你部署了一個 FlinkDeployment,其資源相關配置如下:
spec:
  jobManager:
    replicas: 1
    resource:
      cpu: 1
      memory: 1024m
  taskManager:
    replicas: 1
    resource:
      cpu: 2
      memory: 2048m

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

spec:
  components:
  - name: jobmanager
    replicaRequirements:
      resourceRequest:
        cpu: "1"
        memory: "1.024"
    replicas: 1
  - name: taskmanager
    replicaRequirements:
      resourceRequest:
        cpu: "2"
        memory: "2.048"
    replicas: 1

此時,FederatedResourceQuota 計算的 FlinkDeployment 佔用的資源量為:

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

注意:該特性​​目前處於 Alpha 階段,需要啓用 MultiplePodTemplatesScheduling 特性開關​​才能使用。

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

更多有關此功能的資料請參考:多 Pod 模板支持。

集羣級故障遷移功能增強

在之前的版本中,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: Directly
      statePreservation:
        rules:
          - aliasLabelName: application.karmada.io/cluster-failover-jobid
            jsonPath: "{ .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 控制器和調度器的性能得到了極大提升。未來,我們將繼續對控制器和調度器進行系統性的性能優化。

相關的詳細測試報告,請參考 [Performance] Overview of performance improvements for v1.15 。

致謝貢獻者

Karmada v1.15 版本包含了來自 39 位貢獻者的 269 次代碼提交,在此對各位貢獻者表示由衷的感謝:

貢獻者列表:

@abhi0324
@abhinav-1305
@Arhell
@Bhaumik10
@CaesarTY
@cbaenziger
@deefreak
@dekaihu
@devarsh10
@greenmoon55
@iawia002
@jabellard
@jennryaz
@liaolecheng
@linyao22
@LivingCcj
@liwang0513
@mohamedawnallah
@mohit-nagaraj
@mszacillo
@RainbowMango
@ritzdevp
@ryanwuer
@samzong
@seanlaii
@SunsetB612
@tessapham
@wangbowen1401
@warjiang
@wenhuwang
@whitewindmills
@whosefriendA
@XiShanYongYe-Chang
@zach593
@zclyne
@zhangsquared
@zhuyulicfc49
@zhzhuang-zju
@zzklachlan

參考資料

[1] Karmada: Open, Multi-Cloud, Multi-Cluster Kubernetes Orchestration | karmada
[2] Karmada v1.15: https://github.com/karmada-io/karmada/releases/tag/v1.15.0
[3] 多 Pod 模板支持: https://github.com/karmada-io/karmada/tree/master/docs/proposals/scheduling/multi-podtemplate-support
[4] [Performance] Overview of performance improvements for v1.15: https://github.com/karmada-io/karmada/issues/6516
[5] GitHub地址:https://github.com/karmada-io/karmada
 
點擊關注,第一時間瞭解華為雲新鮮技術~

 

user avatar yfcs999 頭像
點贊 1 用戶, 點贊了這篇動態!
點贊

Add a new 評論

Some HTML is okay.