摘要：在 Karmada 最新版本 v1.3中，跨集群故障遷移特性支持優雅故障遷移，確保遷移程序足夠平滑，
本文分享自華為云社區《Karmada跨集群優雅故障遷移特性決議》，作者：Karmada社區，
在多云多集群應用場景中，為了提高業務的高可用性，用戶的作業負載可能會被部署在多個集群中，然而當某個集群發生故障時，為保證業務的可用性與連續性，用戶希望故障集群上的作業負載被自動的遷移到其他條件適合的集群中去，從而達成故障遷移的目的，
Karmada 在 v1.0 版本發布之前便已支持跨集群故障遷移能力，經歷過社區多個版本的開發迭代，跨集群故障遷移能力不斷完善，在 Karmada 最新版本 v1.3 （https://github.com/karmada-io/karmada/tree/release-1.3）中，跨集群故障遷移特性支持優雅故障遷移，確保遷移程序足夠平滑，
下面我們對該特性展開決議，
▍回顧：單集群故障遷移
在 Kubernetes 的架構中，Node 作為運行 Pod 實體的單元，不可避免地面臨出現故障的可能性，故障來源不限于自身資源短缺、與 Kubernetes 控制面失去連接等，提供服務的可靠性、在節點故障發生后保持服務的穩定一直是 Kubernetes 關注的重點之一，在 Kubernetes 管理面，當節點出現故障或是用戶不希望在節點上運行 Pod 時，節點狀態將被標記為不可用的狀態，node-controller 會為節點打上污點，以避免新的實體調度到當前節點上、以及將已有的 Pod 實體遷移到其他節點上，
▍集群故障判定
相較于單集群故障遷移，Karmada 的跨集群故障遷移單位由節點變為了集群，Karmada 支持Push 和 Pull 兩種模式來管理成員集群，有關集群注冊的資訊可以參考Cluster Registration（http://karmada.io/docs/next/userguide/clustermanager/cluster-registration/），Karmada 根據集群的心跳來判定集群當前的狀態，集群心跳探測有兩種方式：1.集群狀態收集，更新集群的 .status 欄位（包括 Push 和 Pull 兩種模式）；2.控制面中 karmada-cluster 命名空間下的 Lease 物件，每個 Pull 集群都有一個關聯的 Lease 物件，
集群狀態收集
對于 Push 集群，Karmada 控制面中的 clusterStatus-controller 將定期執行集群狀態的收集任務；對于 Pull 集群，集群中部署的 karmada-agent 組件負責創建并定期更新集群的 .status 欄位，集群狀態的定期更新任務可以通過 --cluster-status-update-frequency 標簽進行配置（默認值為10秒），集群的 Ready 條件在滿足以下條件時將會被設定為 False ：· 集群持續一段時間無法訪問；· 集群健康檢查回應持續一段時間不正常，上述持續時間間隔可以通過 --cluster-failure-threshold 標簽進行配置（默認值為30秒），
集群 Lease 物件更新
每當有 Pull 集群加入時，Karmada將為該集群創建一個 Lease 物件和一個 lease-controller，每個 lease-controller 負責更新對應的 Lease 物件，續租時間可以通過 --cluster-lease-duration 和 --cluster-lease-renew-interval-fraction 標簽進行配置（默認值為10秒），由于集群的狀態更新由 clusterStatus-controller 負責維護，因此 Lease 物件的更新程序與集群狀態的更新程序相互獨立，Karmada 控制面中的 cluster-controller 將每隔 --cluster-monitor-period 時間（默認值為5秒）檢查 Pull 集群的狀態，當 cluster-controller 在 --cluster-monitor-grace-period 時間段（默認值為40秒）內沒有收到來著集群的訊息時，集群的 Ready 條件將被更改為 Unknown ，
檢查集群狀態
你可以使用 kubectl 命令來檢查集群的狀態細節：kubectl describe cluster
▍故障遷移程序
集群污點添加
當集群被判定為不健康之后，集群將會被添加上Effect值為NoSchedule的污點，具體情況為： · 當集群 Ready 狀態為 False 時，將被添加如下污點：key: cluster.karmada.io/not-ready effect: NoSchedule· 當集群 Ready 狀態為 Unknown 時，將被添加如下污點：key: cluster.karmada.io/unreachable effect: NoSchedule 如果集群的不健康狀態持續一段時間（該時間可以通過 --failover-eviction-timeout 標簽進行配置，默認值為5分鐘）仍未恢復，集群將會被添加上Effect值為NoExecute的污點，具體情況為：
·當集群 Ready 狀態為 False 時，將被添加如下污點：key: cluster.karmada.io/not-ready effect: NoExecute
·當集群 Ready 狀態為 Unknown 時，將被添加如下污點：key: cluster.karmada.io/unreachable effect: NoExecute
容忍集群污點
當用戶創建 PropagationPolicy/ClusterPropagationPolicy 資源后，Karmada 會通過 webhook 為它們自動增加如下集群污點容忍（以 PropagationPolicy 為例）：
apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx-propagation namespace: default spec: placement: clusterTolerations: - effect: NoExecute key: cluster.karmada.io/not-ready operator: Exists tolerationSeconds: 600 - effect: NoExecute key: cluster.karmada.io/unreachable operator: Exists tolerationSeconds: 600 ...
其中，tolerationSeconds 值可以通過 --default-not-ready-toleration-seconds 與--default-unreachable-toleration-seconds 標簽進行配置，這兩個標簽的默認值均為600，
故障遷移
當 Karmada 檢測到故障群集不再被 PropagationPolicy/ClusterPropagationPolicy 容忍時，該集群將被從資源調度結果中移除，隨后，karmada-scheduler 重調度相關作業負載，重調度的程序有以下幾個限制：·對于每個重調度的作業負載，其仍然需要滿足PropagationPolicy/ClusterPropagationPolicy 的約束，如 ClusterAffinity 或 SpreadConstraints ，· 應用初始調度結果中健康的集群在重調度程序中仍將被保留，
-復制 Duplicated 調度型別
對于 Duplicated 調度型別，當滿足分發策略限制的候選集群數量不小于故障集群數量時，將根據故障集群數量將作業負載重新調度到候選集群；否則，不進行重調度，
... placement: clusterAffinity: clusterNames: - member1 - member2 - member3 - member5 spreadConstraints: - maxGroups: 2 minGroups: 2 replicaScheduling: replicaSchedulingType: Duplicated ...
假設有5個成員集群，初始調度結果在 member1和 member2 集群中，當 member2 集群發生故障，觸發 karmada-scheduler 重調度，
需要注意的是，重調度不會洗掉原本狀態為 Ready 的集群 member1 上的作業負載，在其余3個集群中，只有 member3 和 member5 匹配 clusterAffinity 策略，由于傳播約束的限制，最后應用調度的結果將會是 [member1, member3] 或 [member1, member5] ，
-分發 Divided 調度型別
對于 Divided 調度型別，karmada-scheduler 將嘗試將應用副本遷移到其他健康的集群中去，
... placement: clusterAffinity: clusterNames: - member1 - member2 replicaScheduling: replicaDivisionPreference: Weighted replicaSchedulingType: Divided weightPreference: staticWeightList: - targetCluster: clusterNames: - member1 weight: 1 - targetCluster: clusterNames: - member2 weight: 2 ...
Karmada-scheduler 將根據權重表 weightPreference 來劃分應用副本數，初始調度結果中， member1 集群上有1個副本，member2 集群上有2個副本，當 member1 集群故障之后，觸發重調度，最后的調度結果是 member2 集群上有3個副本，
▍優雅故障遷移
為了防止集群故障遷移程序中服務發生中斷，Karmada 需要確保故障集群中應用副本的洗掉動作延遲到應用副本在新集群上可用之后才執行，ResourceBinding/ClusterResourceBinding 中增加了 GracefulEvictionTasks 欄位來表示優雅驅逐任務佇列：
// GracefulEvictionTasks holds the eviction tasks that are expected to perform // the eviction in a graceful way. // The intended workflow is: // 1. Once the controller(such as 'taint-manager') decided to evict the resource that // is referenced by current ResourceBinding or ClusterResourceBinding from a target // cluster, it removes(or scale down the replicas) the target from Clusters(.spec.Clusters) // and builds a graceful eviction task. // 2. The scheduler may perform a re-scheduler and probably select a substitute cluster // to take over the evicting workload(resource). // 3. The graceful eviction controller takes care of the graceful eviction tasks and // performs the final removal after the workload(resource) is available on the substitute // cluster or exceed the grace termination period(defaults to 10 minutes). // // +optional GracefulEvictionTasks []GracefulEvictionTask `json:"gracefulEvictionTasks,omitempty"`
當故障集群被 taint-manager 從資源調度結果中洗掉時，它將被添加到優雅驅逐任務佇列中，gracefulEvction-controller 負責處理優雅驅逐任務佇列中的任務，在處理程序中，gracefulEvction-controller 逐個評估優雅驅逐任務佇列中的任務是否可以從佇列中移除，判斷條件如下：
- 檢查當前資源調度結果中資源的健康狀態，如果資源健康狀態為健康，則滿足條件，
- 檢查當前任務的等待時長是否超過超時時間，超時時間可以通過graceful-evction-timeout 標簽進行配置（默認為10分鐘），如果超過，則滿足條件，
▍總結
Karmada 跨集群優雅故障遷移特性提升了集群故障后業務的平滑遷移能力，希望通過上述分析程序能幫大家更好的理解和使用Karmada 跨集群故障遷移能力，有關該特性的更多詳細資訊可以參考 Karmada 官網，大家也可以查看 Karmada release （https://github.com/karmada-io/karmada/releases）來跟進 Karmada 最新版本動態，如果大家對 Karmada 跨集群故障遷移特性有更多興趣與見解，或是對其他特性和功能感興趣，也歡迎大家積極參與到 Karmada 社區中來，參與社區討論與開發，附：Karmada社區技術交流地址
專案地址：
https://github.com/karmada-io/karmada
Slack地址：https://slack.cncf.io/
點擊關注，第一時間了解華為云新鮮技術~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/538171.html
標籤：其他