Karmada v1.3：更優雅 更精準 更高效
摘要：最新發布的1.3版本中，Karmada重新設計了應用跨集群故障遷移功能，實現了基於污點的故障驅逐機制，並提供平滑的故障遷移過程，可以有效保障服務遷移過程的連續性（不斷服）。
本文分享自華為雲社區《Karmada v1.3：更優雅 更精準 更高效》，作者：雲容器大未來。
Karmada是開放的多雲多集群容器編排引擎，旨在幫助用戶在多雲環境下部署和運維業務應用。憑藉兼容Kubernetes原生API的能力，Karmada可以平滑遷移單集群工作負載，並且仍可保持與Kubernetes周邊生態工具鏈協同。
在最新發布的1.3版本中，Karmada重新設計了應用跨集群故障遷移功能，實現了基於污點的故障驅逐機制，並提供平滑的故障遷移過程，可以有效保障服務遷移過程的連續性（不斷服）。
本版本新增加的特性：
- 增加了面向多集群的資源代理新特性，通過該代理平台業務方可以在不感知多集群的情況下，以單集群訪問姿勢直接操縱部署在多集群的工作負載；
- 提供針對集群資源建模能力，通過自定義的集群資源模型，調度器可以更精準地進行資源調度；
- 提供基於Bootstrap令牌來註冊Pull模式集群的能力，不僅可以簡化集群註冊過程，還可以方便地進行許可權控制；
此外，基於生產環境的用戶回饋，本版本還進行了諸多性能優化，系統運行過程中CPU和記憶體資源需求大大降低，詳細的性能測試報告稍後發布。
與之前版本一樣，v1.3與前面的版本仍然保持兼容，前面版本的用戶仍可以平滑升級。
新特性概覽
基於污點的優雅驅逐
當集群被判定為故障，並且故障時間超過寬限期（默認5分鐘）之後，Karmada將為故障集群添加「NoExecute」污點，隨後新引入的taint-manager控制器將開始驅逐該故障集群上的工作負載，接著調度器重新調度被驅逐的工作負載至新的可用集群，如果用戶開啟了GracefulEviction特性，被驅逐的工作負載並不會被立即刪除，而是延遲到新的工作負載運行之後，可以保障驅逐過程中業務不中斷。
整體故障遷移過程可以表示成：」集群故障判定」 → 「負載預驅逐」 → 「重新調度」 → 「清理冗餘負載」。
此處，無論故障判定還是驅逐，用戶都可以參過參數來控制：
- –failover-eviction-timeout，指定從調度結果中刪除故障集群的寬限期，默認5分鐘
- –default-not-ready-toleration-seconds，指定默認情況下添加到尚未具有notReady:NoExecute容忍的傳播策略上的容忍時間，默認600秒
- –default-unreachable-toleration-seconds，指定默認情況下添加到尚未具有unreachable:NoExecute容忍的傳播策略上的容忍時間，默認600秒
- –graceful-eviction-timeout，指定自工作負載已移動到優雅驅逐任務以來，等待優雅驅逐控制器執行最終刪除的超時時間，默認時長10分鐘
跨多群集資源的全局代理
Karmada在1.2版本中新增了一個「karmada-search」組件，該組件為選裝組件，用於快取集群中部署的資源對象和事件，並通過搜索API對外提供檢索服務。
1.3版本中，我們在該組件中引入了一個新的代理功能，允許用戶以訪問單集群的方式訪問多集群中的資源，無論資源是否由Karmada管理，利用代理功能，用戶可以統一通過Karmada控制面來操作成員集群中的資源。
用戶可以使用ResourceRegistry API來指定快取的資源類型以及數據源（目標集群），例如以下配置表示從member1 和member2兩個集群中快取Pod與Node資源：
apiVersion: search.karmada.io/v1alpha1 kind: ResourceRegistry metadata: name: proxy-sample spec: targetCluster: clusterNames: - member1 - member2 resourceSelectors: - apiVersion: v1 kind: Pod - apiVersion: v1 kind: Node
將該配置提交給karmada-apiserver之後，便可使用URL：/apis/search.karmada.io/v1alpha1/proxying/karmada/proxy/api/v1/namespaces/default/pods來進行集群資源訪問。該URL中/apis/search.karmada.io/v1alpha1/proxying/karmada/proxy為固定前綴，後面部分與Kubernetes原生API路徑完全一致。
關於該特性的更多資訊可以參考：//karmada.io/docs/userguide/globalview/proxy-global-resource/
基於自定義集群資源模型的調度
在集群調度的過程中，karmada-scheduler會基於一系列的因素來做調度決策，其中一個不可或缺的因素就是集群的可用資源。之前的版本中，Karmada採用了一種通用的資源模型ResourceSummary來抽象集群的可用情況，如下所示：
resourceSummary: allocatable: cpu: "1024" memory: 4096Mi pods: "110" allocated: cpu: "512" memory: 2048Mi pods: "64"
但是ResourceSummary機械地累加了集群中所有節點的資源，忽視了節點上的碎片資源，這會導致資源需求較大的Pod無法準確地調度到合適的集群。同時它也忽視了不同用戶的集群中節點可分配的資源不完全相同的特點。
1.3版本中Karmada引入了一種新的方式——自定義集群資源模型，來抽象集群的可用資源情況，旨在使調度器調度集群的結果更精確。用戶可以啟用–CustomizedClusterResourceModeling的特性開關來啟用這一特性，開啟後，在集群被Karmada所納管後，Karmada會自動地為集群設置默認的資源模型，這一資源模型將集群中的各個節點分為不同等級的模型，默認的資源模型將根據CPU和記憶體這兩項資源指標把節點分為9個不同的等級，如下所示：
resourceModels: - grade: 0 ranges: - max: "1" min: "0" name: cpu - max: 4Gi min: "0" name: memory - grade: 1 ranges: - max: "2" min: "1" name: cpu - max: 16Gi min: 4Gi name: memory ..... - grade: 8 ranges: - max: "9223372036854775807" min: "128" name: cpu - max: "9223372036854775807" min: 1Ti name: memory
Cluster-status-controller將會收集集群內的節點、Pod資訊計算對應模型節點的數量，與此同時，karmada-scheduler根據將要調度的實例資源請求比較不同集群中滿足要求的節點數，並將實例調度到滿足要求的節點更多的集群。
同時，在一些場景下，默認的集群資源模型不能滿足用戶特定集群的需求，現在用戶可以通過kubectl edit cluster命令自定義地設置集群的資源模型，使資源模型能夠更好地擬合集群的資源拓撲。
基於Bootstrap令牌的集群註冊
1.3版本中，對於 Pull 模式下的集群，我們提供了一種通過命令行向 Karmada 控制面註冊的方式。現在通過karmadactl token命令我們可以輕鬆的創建Bootstrap啟動令牌的token，token的默認有效時長是24小時。
$ karmadactl token create --print-register-command --kubeconfig /etc/karmada/karmada-apiserver.config
# The example output is shown below karmadactl register 10.10.x.x:32443 --token t2jgtm.9nybj0526mjw1jbf --discovery-token-ca-cert-hash sha256:f5a5a43869bb44577dba582e794c3e3750f2050d62f1b1dc80fd3d6a371b6ed4
通過karmadactl register命令可以在不複製成員集群kubeconfig的情況下非常輕鬆地完成包括部署karmada-agent在內的註冊過程，增強了控制面以Pull模式納管成員集群的易用性和安全性。
$ karmadactl register 10.10.x.x:32443 --token t2jgtm.9nybj0526mjw1jbf --discovery-token-ca-cert-hash sha256:f5a5a43869bb44577dba582e794c3e3750f2050d62f1b1dc80fd3d6a371b6ed4 # The example output is shown below [preflight] Running pre-flight checks [prefligt] All pre-flight checks were passed [karmada-agent-start] Waiting to perform the TLS Bootstrap [karmada-agent-start] Waiting to construct karmada-agent kubeconfig [karmada-agent-start] Waiting the necessary secret and RBAC [karmada-agent-start] Waiting karmada-agent Deployment W0825 11:03:12.167027 29336 check.go:52] pod: karmada-agent-5d659b4746-wn754 not ready. status: ContainerCreating ...... I0825 11:04:06.174110 29336 check.go:49] pod: karmada-agent-5d659b4746-wn754 is ready. status: Running cluster(member3) is joined successfully
版本升級
我們驗證了從karmada 1.2版本到1.3版本的升級路徑，升級過程平滑，可參考升級文檔：//karmada.io/docs/administrator/upgrading/v1.2-v1.3
致謝貢獻者
Karmada v1.3版本包含了來自51位貢獻者的數百次程式碼提交，在此對各位貢獻者表示由衷的感謝：
貢獻者GitHub ID：
@AllenZMC
@calvin0327
@carlory
@CharlesQQ
@Charlie17Li
@chaunceyjiang
@cutezhangq
@dapengJacky
@dddddai
@duanmengkk
@Fish-pro
@Garrybest
@gy95
@halfrost
@hanweisen
@huntsman-li
@ikaven1024
@joengjyu
@JoshuaAndrew
@kerthcet
@kevin-wangzefeng
@kinzhi
@likakuli
@lonelyCZ
@luoMonkeyKing
@maoyangLiu
@mathlsj
@mikeshng
@Momeaking
@mrlihanbo
@my-git9
@nuclearwu
@Poor12
@prodanlabs
@RainbowMango
@suwliang3
@TheStylite
@wawa0210
@weilaaa
@windsonsea
@wlp1153468871
@wuyingjun-lucky
@XiShanYongYe-Chang
@xuqianjins
@xyz2277
@yusank
@yy158775
@zgfh
@zhixian82
@zhuwint
@zirain
參考鏈接
● Release Notes://github.com/karmada-io/karmada/releases/tag/v1.3.0
● 集群故障遷移使用指導：//karmada.io/docs/userguide/failover/#concept
● 多集群資源全局代理使用指導：//karmada.io/docs/userguide/globalview/proxy-global-resource/
● 集群資源模型使用指導：//karmada.io/docs/userguide/scheduling/cluster-resources
● 基於Bootstrap令牌的集群註冊使用指導：//karmada.io/docs/userguide/clustermanager/cluster-registration
添加小助手微信k8s2222，進入Karmada社區交流群
