一、背景

RocketMQ無論采用Master/Slave的主從模式，還是采用Dledger的多副本模式，均能保證RocketMQ集群的高可用性，但在一些極端場景下，例如機(jī)房斷電、機(jī)房火災(zāi)、地震等不可抗拒因素使得該IDC可用區(qū)的RocketMQ集群無法正常對(duì)外提供消息服務(wù)能力。因此，為了增強(qiáng)抗風(fēng)險(xiǎn)能力，消息隊(duì)列RocketMQ集群多活異地容災(zāi)極為重要。

二、物理部署異地容災(zāi)方案

圖2-1 物理部署異地容災(zāi)方案圖

移動(dòng)云部署的RocketMQ采用的Master/Slave的主從模式，其中物理部署異地容災(zāi)的方案包括以下幾部分：

(1) NameServer組件作為輕量級(jí)注冊中心，無狀態(tài)，負(fù)責(zé)更新和發(fā)現(xiàn) Broker服務(wù)Namesrv之間相互沒有通信，單臺(tái)Namesrv宕機(jī)不影響其他Namesrv節(jié)點(diǎn)與集群的功能，兩臺(tái)Namesrv部署在不同的可用區(qū)，當(dāng)一個(gè)可用區(qū)故障，另外一個(gè)可用區(qū)的Namesrv依然能對(duì)外提供服務(wù)。

(2) Broker組件作為消息中轉(zhuǎn)角色，負(fù)責(zé)存儲(chǔ)消息，轉(zhuǎn)發(fā)消息，采用Master/Slave部署模式，在兩個(gè)可用區(qū)上交叉部署（如broker-a的Master部署在可用區(qū)1上，Slave節(jié)點(diǎn)部署在可用區(qū)2上，broker-b的Master部署在可用區(qū)2上，Slave節(jié)點(diǎn)部署在可用區(qū)1上），消息發(fā)送到Master節(jié)點(diǎn)后會(huì)實(shí)時(shí)同步到Slave節(jié)點(diǎn)，保證每個(gè)可用區(qū)保存了全量的消息。當(dāng)單個(gè)可用區(qū)故障也會(huì)對(duì)外提供消息的讀寫能力。

三、云化版本異地容災(zāi)單集群方案

針對(duì)物理機(jī)部署RocketMQ運(yùn)維、遷移、擴(kuò)縮容費(fèi)時(shí)費(fèi)力，操作復(fù)雜；業(yè)務(wù)增加以后，資源無法彈性，手動(dòng)擴(kuò)縮容實(shí)時(shí)性差；底層資源利用率不高，用戶資源隔離和流量的管控需要額外投入等問題?？梢越柚鶮8S Operator，Operator 的工作原理，實(shí)際上是利用了 Kubernetes 的自定義 API 資源（如使用CRD，CustomResourceDefinition），來描述想要部署的應(yīng)用；然后在自定義控制器里，根據(jù)自定義 API 對(duì)象的變化，來完成具體的部署和運(yùn)維工作，實(shí)現(xiàn)Operator主要關(guān)鍵是 CRD（自定義資源）和 Controller（控制器）的設(shè)計(jì)。

圖3-1 Operator原理圖

自研了RocketMQ Operator實(shí)現(xiàn)集群的秒級(jí)部署，擴(kuò)縮容，規(guī)格變更等一些列常見的運(yùn)維操作，進(jìn)而解決在物理部署所帶來的難題。下圖是RocketMQ Operator設(shè)計(jì)實(shí)現(xiàn)：

圖3-2 RocketMQ Operator架構(gòu)圖

該方案使用三個(gè)異地可用區(qū)部署一個(gè)K8S集群，每個(gè)可用區(qū)部署一個(gè)master節(jié)點(diǎn)，圖中的Broker是兩主兩從高可用方案，采用交叉部署，namesrv每個(gè)可用區(qū)部署一個(gè)實(shí)例。

圖3-3 云化異地容災(zāi)單集群方案

這個(gè)方案存在幾個(gè)問題：大規(guī)模單K8S集群出現(xiàn)故障時(shí)可能會(huì)對(duì)整個(gè)集群產(chǎn)生影響，且組件升級(jí)難、風(fēng)險(xiǎn)大；隨著業(yè)務(wù)增加，核心組件壓力增大，性能下降；單一集群的建設(shè)可能受限于特定的地理位置和前期規(guī)劃，缺乏靈活性。

四、云化版本異地容災(zāi)集群聯(lián)邦方案

針對(duì)上述方案的缺點(diǎn)，消息隊(duì)列RocketMQ云化版本多可用區(qū)的現(xiàn)階段優(yōu)化為如下方案：

圖4-1 云化異地容災(zāi)多聯(lián)邦集群方案

K8S集群采用云原生Kosmos進(jìn)行多個(gè)集群聯(lián)邦，不在單純依賴單個(gè)K8S集群，RocketMQ服務(wù)資源通過Kosmos CluterTree同步聯(lián)邦集群間的svc，pod等資源 ，聯(lián)邦集群間的網(wǎng)絡(luò)由Kosmos ClusterLink打通。

五、Kosmos簡介

Kosmos是移動(dòng)云的分布式云原生聯(lián)邦集群技術(shù)集合，于2023年8月開源，項(xiàng)目地址：https://github.com/kosmos-io/kosmos。Kosmos包含多集群網(wǎng)絡(luò)工具ClusterLink、跨集群編排工具ClusterTree等：

圖5-1 Kosmos模塊和組件

ClusterLink的作用是打通多個(gè)Kubernetes集群之間的網(wǎng)絡(luò)，在CNI上層實(shí)現(xiàn)，用戶無需卸載或重啟已經(jīng)安裝的CNI插件，且不會(huì)對(duì)正在運(yùn)行的pod產(chǎn)生影響。ClusterLink的主要功能如下：

? 提供跨集群PodIP、ServiceIP互訪能力

  ? 提供P2P、Gateway多種網(wǎng)絡(luò)模式

  ? 支持全局IP分配

  ? 支持IPv4、IPv6雙棧

ClusterTree的作用是實(shí)現(xiàn)Kubernetes的樹形擴(kuò)展和應(yīng)用的跨集群編排。ClusterTree本質(zhì)是一組控制器，用戶可以像使用單集群那樣直接與控制面kube-apiserver進(jìn)行交互，不需要額外的代碼改造。目前，ClusterTree包含的主要功能如下：

?提供創(chuàng)建跨集群應(yīng)用能力

  ?兼容k8s api，用戶零改造

  ?支持有狀態(tài)應(yīng)用

  ?支持k8s-native（需要訪問kube-apiserver的）應(yīng)用

除此之外，Kosmos還提供一些輔助工具，其中，kosmos-operator簡化了Kosmos部署。Kosmosctl是一款命令行工具，為用戶提供網(wǎng)絡(luò)連通性測試、集群納管、Kosmos部署安裝等功能。

六、Kosmos多集群網(wǎng)絡(luò)ClusterLink

（一）ClusterLink工作流程和原理

ClusterLink基于linux隧道技術(shù)打通跨集群網(wǎng)絡(luò)，隧道類型是可配置的，例如：VxLAN或IPSec。ClusterLink包含Network-Manager、Agent等多個(gè)組件，如下圖所示淺藍(lán)色部分。各個(gè)組件相互協(xié)作完成隧道、路由表、fdb等網(wǎng)絡(luò)配置。

圖 6-1 ClusterLink架構(gòu)

其工作流程如下：

• 首先，位于各個(gè)子集群的Controller-Manager組件負(fù)責(zé)收集集群信息，如：podCIDR、serviceCIDR、node信息等，這些信息在不同的CNI插件下會(huì)保存在不同位置，因此Controller-Manager包含一些插件來適配CNI。收集的集群信息會(huì)保存在兩個(gè)自定義資源：Cluster、ClusterNode中。
• 然后，Network-Manager組件監(jiān)聽到這兩個(gè)CR的變化，實(shí)時(shí)計(jì)算各個(gè)節(jié)點(diǎn)所需的網(wǎng)絡(luò)配置，如：網(wǎng)卡信息、路由表、iptables、arp等等。對(duì)應(yīng)節(jié)點(diǎn)的網(wǎng)絡(luò)配置信息保存在NodeConfig自定義資源對(duì)象中。
• 接下來，作為網(wǎng)絡(luò)配置的具體實(shí)施者，agent，一個(gè)daemonset，負(fù)責(zé)讀取對(duì)應(yīng)節(jié)點(diǎn)的網(wǎng)絡(luò)配置，進(jìn)行底層網(wǎng)絡(luò)配置。待網(wǎng)絡(luò)配置完成后，pod即可通過podIP、serviceIP進(jìn)行跨集群訪問。

（二）ClusterLink網(wǎng)絡(luò)模式介紹

圖 6-2 ClusterLink網(wǎng)絡(luò)模式

目前，ClusterLink包含兩種網(wǎng)絡(luò)模式：Gateway和P2P。在Gateway模式中，數(shù)據(jù)包由左側(cè)pod發(fā)出后，先經(jīng)由集群內(nèi)隧道vx-local到達(dá)該集群gateway節(jié)點(diǎn)。然后再走跨集群隧道到達(dá)對(duì)端集群。數(shù)據(jù)包到達(dá)對(duì)端集群后，交由CNI處理，走單集群網(wǎng)絡(luò)到達(dá)目標(biāo)pod。該模式有利有弊，其優(yōu)勢在于每個(gè)集群只需要1個(gè)節(jié)點(diǎn)（考慮HA時(shí)需要2個(gè)）提供對(duì)外訪問即可，適用于跨云混合云場景。缺點(diǎn)是因?yàn)榫W(wǎng)絡(luò)路徑較長，有一定的性能損耗。針對(duì)此問題，ClusterLink提供P2P模式，對(duì)網(wǎng)絡(luò)性能要求較高的場景可以使用此模式。在該模式下，數(shù)據(jù)包的控制粒度更細(xì)，會(huì)直接發(fā)往對(duì)端pod所在節(jié)點(diǎn)。此外，P2P和Gateway兩種模式支持混合使用。

七、Kosmos跨集群編排ClusterTree

（一）ClusterTree 組件和原理介紹

ClusterTree實(shí)現(xiàn)了Kubernetes的樹形擴(kuò)展和應(yīng)用的跨集群編排，用戶可以像使用單集群那樣訪問root kube-apiserver。Leaf集群作為節(jié)點(diǎn)添加在root集群中，用戶可以使用k8s原生的方式控制pod分布，例如：labelSelector、親和/反親和、污點(diǎn)和容忍、拓?fù)浞植技s束等。

圖 7-1 ClusterTree 架構(gòu)

ClusterTree其本質(zhì)是一組控制器，各個(gè)控制器的作用如下：

• node-controller：節(jié)點(diǎn)資源計(jì)算；節(jié)點(diǎn)狀態(tài)維護(hù)；節(jié)點(diǎn)lease更新
• pod-controller：監(jiān)聽root集群pod創(chuàng)建，調(diào)用leaf集群kube-apiserver進(jìn)行pod創(chuàng)建；維護(hù)pod狀態(tài)；環(huán)境變量轉(zhuǎn)換；權(quán)限注入
• storagecopy-controller：pv/pvc資源同步和狀態(tài)管理
• mcs-controller：service資源同步和狀態(tài)管理

（二）ClusterTree 高可用介紹

當(dāng)出現(xiàn)AZ級(jí)故障，或者AZ之間網(wǎng)絡(luò)中斷，確保用戶正常訪問RocketMQ集群實(shí)例是非常重要的。如上圖所示，為了應(yīng)對(duì)A處網(wǎng)絡(luò)斷開或者控制面故障，ClusterTree實(shí)現(xiàn)了service和endpoint資源的同步，讓用戶訪問流量直接從子集群走，解耦了管理和業(yè)務(wù)，也縮短了網(wǎng)絡(luò)路徑。RocketMQ的nameserver pod是跨集群分布，當(dāng)B處網(wǎng)絡(luò)斷開或者某個(gè)AZ故障，會(huì)導(dǎo)致用戶有50%概率訪問失敗的nsv pod。針對(duì)此問題，ClusterTree的eps-probe插件會(huì)周期對(duì)跨集群ep進(jìn)行探測，并移除失效endpoint。

圖 7-2 RocketMQ跨AZ高可用

八、Kosmos 集群負(fù)載和網(wǎng)絡(luò)性能測試

ClusterTree能管理多少節(jié)點(diǎn)和pod？ClusterLink較單集群網(wǎng)絡(luò)的性能如何？這些都是用戶非常關(guān)注的問題，對(duì)此我們也做了相應(yīng)的測試。

（一）集群負(fù)載測試

1. 測試標(biāo)準(zhǔn)
   Kubernetes官方給出3條SLIs（Service Level Indicator，服務(wù)水平指標(biāo)），并給出對(duì)應(yīng)的SLOs（Service Level Objective，服務(wù)水平目標(biāo)）值。SLIs包括：讀寫延遲、無狀態(tài)pod啟動(dòng)時(shí)間（不含鏡像拉取和init容器啟動(dòng)），文檔地址：https://github.com/kubernetes/community/blob/master/sig-scalability/slos/slos.md
2. 測試工具

• ClusterLoader2
  ClusterLoader2 能夠針對(duì)Kubernetes 定義的SLIs/SLOs 指標(biāo)進(jìn)行測試，檢驗(yàn)集群是否符合各項(xiàng)服務(wù)質(zhì)量標(biāo)準(zhǔn)。ClusterLoader2 最終會(huì)輸出一份Kubernetes集群性能報(bào)告，展示一系列性能指標(biāo)測試結(jié)果。https://github.com/kubernetes/perf-tests/tree/master/clusterloader2
• Kwok
  道客開源項(xiàng)目，用于快速模擬大規(guī)模集群。https://github.com/kubernetes-sigs/kwok

3. 測試方法

圖 8-1 集群負(fù)載測試-測試方法

如圖所示，我們首先通過kwok創(chuàng)建了20個(gè)大規(guī)模集群，每個(gè)集群包含5000個(gè)節(jié)點(diǎn)，我們將這些集群使用Kosmos進(jìn)行納管。接下來，使用clusterloader2 連接控制面kube-apiserver進(jìn)行集群負(fù)載測試，其關(guān)鍵測試參數(shù)如圖所示。

4. 測試結(jié)果

圖 8-2 集群負(fù)載測試-測試結(jié)果

使用kosmos管理k8s集群聯(lián)邦，在 100,000 節(jié)點(diǎn)和 200,000 pod場景下，達(dá)到官方SLOs標(biāo)準(zhǔn)，并且該規(guī)模并未達(dá)到kosmos上限。

（二）網(wǎng)絡(luò)性能測試

1. 測試工具
   iperf3
2. 評(píng)估標(biāo)準(zhǔn)
   我們使用RTT（Round-Trip Time）時(shí)延來評(píng)估性能優(yōu)劣。RTT即：往返時(shí)延，表示發(fā)送端從發(fā)送數(shù)據(jù)開始，到發(fā)送端收到來自接收端的確認(rèn)（接收端收到數(shù)據(jù)后即發(fā)送確認(rèn)），總共經(jīng)歷的時(shí)延。
3. 測試方法
   比對(duì)單集群網(wǎng)絡(luò)和跨集群網(wǎng)絡(luò)的RTT時(shí)延，如下圖所示1、2部分：

圖 8-3 網(wǎng)絡(luò)性能測試-測試方法

4. 測試結(jié)果
   跨集群相對(duì)于單集群，RTT時(shí)延增加6%左右。

圖片