本文分享自華為雲社群《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/
點選下方，第一時間了解華為雲新鮮技術~
華為雲部落格_大資料部落格_AI部落格_雲計算部落格_開發者中心-華為雲