RocketMQ基於Kosmos實現AZ級高可用，你學會了嗎？

一、背景

RocketMQ無論採用Master/Slave的主從模式，還是採用Dledger的多副本模式，均能保證RocketMQ集群的高可用性，但在一些極端場景下，例如機房斷電、機房火災、地震等不可抗拒因素使得該IDC可用區的RocketMQ叢集無法正常對外提供訊息服務能力。因此，為了增強抗風險能力，訊息佇列RocketMQ叢集多活異地容災極為重要。

二、實體部署異地容災方案

圖2-1 實體部署異地容災方案圖

行動雲部署的RocketMQ採用的Master/Slave的主從模式，其中實體部署異地容災的方案包括以下幾部分：

(1) NameServer元件作為輕量級註冊中心，無狀態，負責更新和發現Broker服務Namesrv之間相互沒有通信，單一Namesrv宕機不影響其他Namesrv節點與叢集的功能，兩台Namesrv部署在不同的可用區，當一個可用區故障，另外一個可用區的Namesrv仍能對外提供服務。

(2) Broker元件作為訊息中轉角色，負責儲存訊息，轉發訊息，採用Master/Slave部署模式，在兩個可用區上交叉部署（如broker-a的Master部署在可用區1上，Slave節點部署在可用區2上，broker-b的Master部署在可用區2上，Slave節點部署在可用區1上），訊息發送到Master節點後會即時同步到Slave節點，保證每個可用區保存了全量的消息。當單一可用區故障也會對外提供訊息的讀寫能力。

三、雲端化版本異地災難單一集群方案

針對實體機部署RocketMQ運維、遷移、擴縮容費時費力，操作複雜；業務增加以後，資源無法彈性，手動擴縮容實時性差；底層資源利用率不高，用戶資源隔離和流量的管控需要額外投入等問題。可以藉助K8S Operator，Operator 的工作原理，實際上是利用了Kubernetes 的自訂API 資源（如使用CRD，CustomResourceDefinition），來描述想要部署的應用；然後在自訂控制器裡，根據自訂API 對象的變化，來完成具體的部署和維運工作，實現Operator主要關鍵是CRD（自訂資源）和Controller（控制器）的設計。

圖3-1 Operator原理圖

自研了RocketMQ Operator實現叢集的秒級部署，擴縮容，規格變更等一些列常見的運維操作，進而解決在實體部署所帶來的難題。下圖是RocketMQ Operator設計實作：

圖3-2 RocketMQ Operator架構圖

此方案使用三個異地可用區部署一個K8S集群，每個可用區部署一個master節點，圖中的Broker是兩主兩從高可用方案，採用交叉部署，namesrv每個可用區部署一個實例。

圖3-3 雲化異地容災單集群方案

這個方案有幾個問題：大規模單K8S叢集發生故障時可能會對整個叢集產生影響，且元件升級困難、風險大；隨著業務增加，核心元件壓力增大，效能下降；單一叢集的建置可能受限於特定的地理位置和前期規劃，缺乏彈性。

四、雲端化版本異地災難集群聯邦方案

針對上述方案的缺點，訊息佇列RocketMQ雲端化版本多可用區的現階段最佳化為如下方案：

圖4-1 雲化異地容災多聯邦集群方案

K8S集群採用雲原生Kosmos進行多個集群聯邦，不在單純依賴單一K8S集群，RocketMQ服務資源透過Kosmos CluterTree同步聯邦集群間的svc，pod等資源，聯邦集群間的網路由Kosmos ClusterLink打通。

五、Kosmos簡介

Kosmos是行動雲的分散式雲端原生聯邦集群技術集合，於2023年8月開源，專案網址：https://github.com/kosmos-io/kosmos。Kosmos包含多集群網路工具ClusterLink、跨集群編排工具ClusterTree等：

圖5-1 Kosmos模組與組件

ClusterLink的作用是打通多個Kubernetes叢集之間的網絡，在CNI上層實現，使用者無需卸載或重啟已安裝的CNI插件，且不會對正在運行的pod產生影響。ClusterLink的主要功能如下：

✓ 提供跨集群PodIP、ServiceIP互访能力

  ✓ 提供P2P、Gateway多种网络模式

  ✓ 支持全局IP分配

  ✓ 支持IPv4、IPv6双栈
1.
2.
3.
4.
5.
6.
7.

ClusterTree的作用是實作Kubernetes的樹狀擴充和應用的跨叢集編排。ClusterTree本質是一組控制器，使用者可以像使用單一叢集那樣直接與控制面kube-apiserver進行交互，不需要額外的程式碼改造。目前，ClusterTree包含的主要功能如下：

✓提供创建跨集群应用能力

  ✓兼容k8s api，用户零改造

  ✓支持有状态应用

  ✓支持k8s-native（需要访问kube-apiserver的）应用
1.
2.
3.
4.
5.
6.
7.

除此之外，Kosmos還提供一些輔助工具，其中，kosmos-operator簡化了Kosmos部署。Kosmosctl是一款命令列工具，為使用者提供網路連通性測試、叢集納管、Kosmos部署安裝等功能。

六、Kosmos多集群網路ClusterLink

（一）ClusterLink工作流程與原理

ClusterLink基於linux隧道技術打通跨集群網絡，隧道類型是可設定的，例如：VxLAN或IPSec。ClusterLink包含Network-Manager、Agent等多個元件，如下圖所示淺藍色部分。各個元件相互協作完成隧道、路由表、fdb等網路設定。

圖6-1 ClusterLink架構

其工作流程如下：

• 首先，位於各個子集群的Controller-Manager組件負責收集集群信息，如：podCIDR、serviceCIDR、node信息等，這些信息在不同的CNI插件下會保存在不同位置，因此Controller-Manager包含一些插件來適配CNI。收集的叢集資訊會保存在兩個自訂資源：Cluster、ClusterNode。
• 然後，Network-Manager元件監聽到這兩個CR的變化，即時計算各個節點所需的網路配置，如：網路卡資訊、路由表、iptables、arp等等。對應節點的網路設定資訊保存在NodeConfig自訂資源物件中。
• 接下來，作為網路配置的具體實施者，agent，一個daemonset，負責讀取對應節點的網路配置，進行底層網路配置。待網路設定完成後，pod即可透過podIP、serviceIP進行跨叢集存取。

（二）ClusterLink網路模式介紹

圖6-2 ClusterLink網路模式

目前，ClusterLink包含兩種網路模式：Gateway和P2P。在Gateway模式中，封包由左側pod發出後，先經由集群內隧道vx-local到達該集群gateway節點。然後再走跨集群隧道到達對端集群。封包到達對端叢集後，交由CNI處理，走單集群網路到達目標pod。此模式有利有弊，其優勢在於每個叢集只需要1個節點（考慮HA時需要2個）提供對外存取即可，適用於跨雲混合雲場景。缺點是因為網路路徑較長，有一定的效能損耗。針對此問題，ClusterLink提供P2P模式，網路效能要求較高的場景可以使用此模式。在該模式下，封包的控製粒度更細，會直接傳送到對端pod所在節點。此外，P2P和Gateway兩種模式支援混合使用。

七、Kosmos跨集群編排ClusterTree

（一）ClusterTree 組件與原理介紹

ClusterTree實作了Kubernetes的樹狀擴充和應用的跨叢集編排，使用者可以像使用單一叢集一樣存取root kube-apiserver。Leaf叢集作為節點加入在root叢集中，使用者可以使用k8s原生的方式控制pod分佈，例如：labelSelector、親和/反親和、污點和容忍、拓撲分佈限制等。

圖7-1 ClusterTree 架構

ClusterTree其本質是一組控制器，各控制器的功能如下：

• node-controller：節點資源計算；節點狀態維護；節點lease更新
• pod-controller：監聽root叢集pod創建，呼叫leaf叢集kube-apiserver進行pod創建；維護pod狀態；環境變數轉換；權限注入
• storagecopy-controller：pv/pvc資源同步與狀態管理
• mcs-controller：service資源同步與狀態管理

（二）ClusterTree 高可用介紹

當出現AZ級故障，或AZ之間網路中斷，確保使用者正常存取RocketMQ叢集實例是非常重要的。如上圖所示，為了因應A處網路斷開或控制面故障，ClusterTree實現了service和endpoint資源的同步，讓用戶存取流量直接從子叢集走，解耦了管理和業務，也縮短了網路路徑。RocketMQ的nameserver pod是跨叢集分佈，當B處網路中斷或某個AZ故障，會導致使用者有50%機率存取失敗的nsv pod。針對此問題，ClusterTree的eps-probe插件會週期對跨集群ep進行探測，並移除失效endpoint。

圖7-2 RocketMQ跨AZ高可用

八、Kosmos 叢集負載和網路效能測試

ClusterTree能管理多少節點和pod？ClusterLink較單集群網路的效能如何？這些都是使用者非常關注的問題，對此我們也做了相對應的測試。

（一）叢集負載測試

1. 測試標準
   Kubernetes官方給予3個SLIs（Service Level Indicator，服務等級指標），並給予對應的SLOs（Service Level Objective，服務等級目標）值。SLIs包括：讀寫延遲、無狀態pod啟動時間（不含鏡像拉取和init容器啟動），文件位址：https://github.com/kubernetes/community/blob/master/sig-scalability/slos/slos .md
2. 測試工具

• ClusterLoader2
  ClusterLoader2 能夠針對Kubernetes 定義的SLIs/SLOs 指標進行測試，檢驗叢集是否符合各項服務品質標準。ClusterLoader2 最終會輸出一份Kubernetes叢集效能報告，展示一系列效能指標測試結果。https://github.com/kubernetes/perf-tests/tree/master/clusterloader2
• Kwok
  道客開源項目，用於快速模擬大規模集群。https://github.com/kubernetes-sigs/kwok

3. 測試方法

圖8-1 叢集負載測試-測試方法

如圖所示，我們首先透過kwok創建了20個大規模集群，每個集群包含5000個節點，我們將這些集群使用Kosmos進行納管。接下來，使用clusterloader2 連線控制面kube-apiserver進行叢集負載測試，其關鍵測試參數如圖所示。

4. 測試結果

圖8-2 叢集負載測試-測試結果

使用kosmos管理k8s集群聯邦，在100,000 節點和200,000 pod場景下，達到官方SLOs標準，且該規模並未達到kosmos上限。

（二）網路效能測試

1. 測試工具
   iperf3
2. 評估標準
   我們使用RTT（Round-Trip Time）延遲來評估效能優劣。RTT即：往返時延，表示發送端從發送資料開始，到發送端收到來自接收端的確認（接收端收到資料後即發送確認），總共經歷的延遲。
3. 測試方法
   比對單集群網路和跨集群網路的RTT時延，如下圖所示1、2部分：

圖8-3 網路效能測試-測試方法

4. 測試結果
   跨集群相對於單一集群，RTT時延增加6%左右。

圖片