Karmada 多云容器編排引擎支持多調度組，助力成本優化-有解無憂

摘要：Karmada 社區也在持續關注云成本的管理，在最近發布的 v1.5 版本中，支持用戶在分發策略 PropagationPolicy/ClusterPropagationPolicy 中設定多個集群調度組，實作將業務調度到成本更低的集群組中去，

本文分享自華為云社區《Karmada 多云容器編排引擎支持多調度組，助力成本優化！》，作者：華為云云原生團隊

根據 Flexera 最新發布的《2023 年云現狀調查報告》，在受訪的750家企業中，使用多云的企業比例高達87%：

在使用多云的受訪者中，排在前兩位的多云挑戰分別是：孤立在不同云上的應用程式和云之間的災難恢復/故障切換，在所有組織中，最常用的多云工具是安全工具，緊隨其后的是成本優化（Finops）工具，

此外，云成本的管理取代了安全性話題，成為當下云使用者面臨的首要問題：

Karmada 社區也在持續關注云成本的管理，在最近發布的 v1.5 版本中，支持用戶在分發策略 PropagationPolicy/ClusterPropagationPolicy 中設定多個集群調度組，實作將業務調度到成本更低的集群組中去，

多調度組

Karmada 的PropagationPolicy 支持宣告單組集群，即.spec.placement.clusterAffinity，其 YAML 配置示例為：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
 name: nginx
spec:
 resourceSelectors:
 - apiVersion: apps/v1
 kind: Deployment
 name: nginx
 placement:
 clusterAffinitiy:
 - clusterNames:
 - member1
 - member2

Karmada v1.5 版本中，clusterAffinity 向 karmada-scheduler 提供一組候選集群，karmada-scheduler 根據相關限制（例如 spreadConstraint，插件過濾等）在候選集群之間做出調度決策，調度結果要么成功，要么失敗，多調度組支持用戶設定ClusterAffinities欄位，在 PropagationPolicy 中宣告多組集群，karmada-scheduler 可以依次來評估每個 clusterAffinity，進而做出決策，此功能允許 Karmada 調度程式在集群故障時首先將應用程式調度到低成本集群組，或將應用程式從主集群遷移到備份集群，

// Placement represents the rule for select clusters.
type Placement struct {
 // ClusterAffinities 表示對 ClusterAffinityTerm 指示的多個集群組的調度限制，
      // 調度程式將按照這些組在規范中出現的順序逐個評估，不滿足調度限制的組將被忽略，
      // 這意味著除非該組中的所有集群也屬于下一個組（同一集群可以屬于多個組），
      // 否則將不會選擇此組中的所有集群，
      // 如果沒有一個組滿足調度限制，則調度失敗，這意味著不會選擇集群，
      // 注：ClusterAffinities 不能與 ClusterAffinity 共存，
      // 如果未同時設定 ClusterAffinities 和 ClusterAffinity，則任何集群都可以作為調度候選集群，
 //
 // +optional
 ClusterAffinities []ClusterAffinityTerm `json:"clusterAffinities,omitempty"`
}
// ClusterAffinityTerm selects a set of cluster.
type ClusterAffinityTerm struct {
 // AffinityName 是集群組的名稱.
 // +required
 AffinityName string `json:"affinityName"`
 ClusterAffinity `json:",inline"`
}

云成本管理使用場景

用戶可以使用多調度組來進行云成本的管理，例如：本地資料中心中的私有集群是主集群組，集群提供商提供的托管集群可以是輔助集群組，因此，Karmada 調度程式更愿意將作業負載調度到主集群組，只有在主集群組不滿足限制（如缺乏資源）的情況下，才會考慮輔助集群組，下面我們給出一個針對成本優化進行調度的例子：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinities:
      - affinityName: local-clusters
        clusterNames:
          - local-member1
          - local-member2
      - affinityName: cloud-clusters
        clusterNames:
          - huawei-member1
          - huawei-member2

上面例子中配置有本地集群組（local-clusters）和云上集群組（cloud-clusters）共兩個集群組，Karmada 在調度 Deployment/nginx 時，會優先嘗試調度到本地集群組中的集群，如果失敗（如缺乏資源），則繼續選擇云上集群組，從而實作在本地集群資源足夠時，優先選擇成本更低的本地集群的目標，

容災與遷移場景

對于災難恢復場景，系統管理員也可以定義主集群組和備份集群組，作業負載將首先調度到主集群組，當主集群組中的集群發生故障（如資料中心斷電）時，Karmada 調度程式可以將作業負載遷移到備份集群組，

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinities:
      - affinityName: primary-cluster
        clusterNames:
          - member1
      - affinityName: backup-cluster
        clusterNames:
          - member2

上面的例子通過配置主集群組（primary-cluster）和備份集群組（backup-cluster），在調度 Deployment/nginx 時，如果主集群組滿足要求，會調度到主集群組中的 member1 集群，當member1 集群故障時，調度器按順序匹配新集群組，從而將業務遷移到備份集群組中的member2 上，這樣就達成了容災的目的，

總結

支持多調度組設定為用戶提供了更豐富的多集群資源分發策略選擇，Karmada 后續也會繼續探索云成本的管理，大家有任何感興趣的想法，都歡迎大家來 Karmada 社區進行討論與分享，

附：Karmada社區交流地址

專案地址：https://github.com/karmada-io/karmada

Slack地址：https://slack.cncf.io/

點擊關注，第一時間了解華為云新鮮技術~

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/550788.html

標籤：其他

上一篇：物聯網常見協議之Amqp協議及使用場景決議

下一篇：返回列表