## 背景

為了降低 [EMQX](https://www.emqx.com/zh/products/emqx) 在 Kubernetes 上的部署、運維成本，我們將一些日常運維能力進行總結、抽象並整合到程式碼中，以 [EMQX Kubernetes Operator](https://www.emqx.com/zh/emqx-kubernetes-operator) 的方式幫助使用者實現 EMQX 的自動化部署和運維。

此前，EMQX Kubernetes Operator v1beta1、v1beta2、v1beta3 的升級策略均為滾動升級，相關升級流程如下:

[![1](http://img.blog.itpub.net/blog/2023/01/16/1b92fc6a76ba589f.png?x-oss-process=style/bb "1")](https://www.emqx.com/zh/blog/how-to-upgrade-emqx-in-kubernetes "1")

## 問題分析

滾動升級在生產環境中可能會面臨以下問題：

1. 升級過程中會逐個銷燬舊的節點再建立新的節點，因此可能導致客戶端多次斷連（最糟糕的情況下斷連次數與節點數量一致），從而影響使用者體驗。
2. 當叢集處於較高連線的情況下，一個節點被銷燬，那麼該節點上面的連線會在瞬間斷開，由客戶端重試邏輯來進行重連；當單節點連線數較大時，如果大量客戶端進行重連，則可能會給服務端造成壓力導致過載。
3. 升級完成後，各節點間的負載不均衡（如上圖：emqx-ee-0 在升級過程中，客戶端可能會進行重連，此時由於 emqx-ee-0 還未就緒，因此可能連線到 emqx-ee-1 或者 emqx-ee-2，升級完成後 emqx-ee-0 上可能只有較少負載或者無負載），從而打破業務容量模型的規劃，可能影響到服務。
4. 由於使用 StatefulSets 進行部署，在升級過程中提供服務的節點會比實際節點要少一個（影響到使用者的業務模型），這可能會增加服務端的一些壓力。

如果上面幾個步驟的問題疊加（多次斷連與大量斷連的客戶端不停的重試連線），則可能會放大客戶端重連的規模，從而造成服務端過載或雪崩。

下圖是在現有升級模式下連線數的監控圖（在不同的業務中會存在差異，比如後端依賴的不同資源、伺服器配置、客戶端重連或重試策略等，均會帶來一些不同的影響）。其中：

- sum：總的連線數，圖中最上面的一條線
- emqx-ee-a：字首表示的是升級前 3 個 EMQX 節點
- emqx-ee-b：字首表示的是升級後 3 個 EMQX 節點

[![2](http://img.blog.itpub.net/blog/2023/01/16/54ffcf35644bc281.png?x-oss-process=style/bb "2")](https://www.emqx.com/zh/blog/how-to-upgrade-emqx-in-kubernetes "2")

在上圖中，當我們開始執行滾動升級時，首先 emqx-ee-a-emqx-ee-2 進行銷燬，並建立新的 emqx-ee-b-emqx-ee-2，此時僅有 emqx-ee-a-emqx-ee-1、emqx-ee-a-emqx-ee-0 能夠提供服務，當客戶端進行重連時，LB 會將流量轉移到 emqx-ee-a-emqx-ee-0、emqx-ee-a-emqx-ee-1 上面，因此我們能夠看到 emqx-ee-a-emqx-ee-1、emqx-ee-a-emqx-ee-0 有明顯的流量上升，當後面更新這兩個 pod 時，意味著客戶端可能多次斷連。由於新 pod 建立的過程存在著時間差，以上圖為例，emqx-ee-a-emqx-ee-0 最後升級，當升級完成後，可能客戶端已經完成重試、重連，此時主要連線已經被另兩個 pod 接納，因此會導致 pod 之間流量不均衡，從而影響到使用者業務模型的評估，或者影響到服務。

為了方便展示，我們未壓測大量連線模擬重連、導致服務端過載的場景（在實際生產環境中可能遇到，TPS 超過雲端規劃的容量模型），但從連線數監控圖上，我們依然看到一個大缺口，說明對業務產生了較大影響。因此我們需制定一種方案來規避以上幾個問題，保障升級過程中的平滑穩定。

## 問題解決

### 目標

1. 升級過程中實現連線數可控遷移（可根據服務端處理能力設定相應的遷移速率）。
2. 升級過程中減少連線斷開的次數（一次斷連）。
3. 在整個升級的過程中始終保持預期的節點來提供服務。
4. 升級完成後，不需要叢集負載重平衡，各節點間的連線相對均衡（與 LB 排程策略有一定關係）。

### 方案設計

藍綠髮布是一種同時執行兩個版本應用的釋出策略。EMQX Kubernetes Operator 近日在 [2.1.0](https://github.com/emqx/emqx-operator/releases/tag/2.1.0) 版本中實現了 EMQX Enterprise 的藍綠髮布，即從現有的 EMQX Enterprise 叢集開始，建立一套新版本的 EMQX Enterprise 叢集，在這一過程中不停止掉老版本，等新版本叢集執行起來後，再將流量逐步平滑切換到新版本上。

從 4.4.12 版本開始，EMQX 企業版本支援**節點疏散**功能。節點疏散功能允許使用者在關閉節點之前強制將連線和會話以一定速率遷移到其他節點，以避免節點關閉帶來的會話資料丟失。

> 關於節點疏散更多資訊請參考[相關檔案](https://docs.emqx.com/zh/enterprise/v4.4/advanced/rebalancing.html)

在 Kubernetes 上我們透過模擬藍綠髮布以及結合節點疏散功能，實現了連線可控遷移，極大減少了斷連的次數（僅斷連一次）。相關升級流程圖如下：

[![3](http://img.blog.itpub.net/blog/2023/01/16/5112aadf5563eb2c.png?x-oss-process=style/bb "3")](https://www.emqx.com/zh/blog/how-to-upgrade-emqx-in-kubernetes "3")

整個升級流程大致可分為以下幾步:

1. 升級時（映象、Pod 相關資源修改調整）我們會先建立一個同規格的節點加入到現有叢集中。
2. 當新節點全部就緒後，我們將 service 全部指向新建立的節點，此時新節點開始接受新的連線請求。
3. 將舊節點從 service 中摘出，此時舊節點不再接收新的連線請求。
4. 透過 EMQX 節點疏散功能，逐個對節點上的連線進行可控遷移，直至連線全部完成遷移，再對節點進行銷燬。

### 操作流程

節點疏散是 EMQX Enterprise 4.4.12 開始支援的新特性，EMQX Kubernetes Operator 在 2.1 版本中對該能力進行適配，如需使用該能力，請將 EMQX 升級到企業版 v4.4.12，EMQX Kubernetes Operator 升級到 v2.1。

- 配置藍綠升級

```dts
apiVersion: apps.emqx.io/v1beta4
...
spec:
   blueGreenUpdate:
    initialDelaySeconds: 60
    evacuationStrategy:
      waitTakeover: 5
      connEvictRate: 200
      sessEvictRate: 200
...
```

`initialDelaySeconds` ：所有的節點就緒後（藍綠節點），開始節點疏散前的等待時間 （由於切換 Service 後，LoadBalancer 需要時間來處理 service 與 pod 的關係）（單位：秒）

`waitTakeover` ：所有連線斷開後，等待客戶端重連以接管會話的時間（單位：秒）

`connEvictRate` ：客戶端每秒斷開連線速度

`sessEvictRate`：`waitTakeover` 之後每秒會話疏散速度

詳情可參考：[Operator 檔案](https://github.com/emqx/emqx-operator/blob/main/docs/en_US/getting-started/getting-started.md)

升級過程中連線數監控圖如下（本次測試以 10 萬連線進行）：

[![4](http://img.blog.itpub.net/blog/2023/01/16/d9a68ca35223e1ab.png?x-oss-process=style/bb "4")](https://www.emqx.com/zh/blog/how-to-upgrade-emqx-in-kubernetes "4")

sum：總的連線數，圖中最上面的一條線

emqx-ee-86d7758868：字首表示的是升級前的 3 個 EMQX 節點

emqx-ee-745858464d：字首表示升級後的 3 個 EMQX 節點

如上圖，我們透過 EMQX Kubernetes Operator 的藍綠髮布在 Kubernetes 中實現了優雅升級，透過該方案升級，總連線數未出現較大抖動（取決於遷移速率、服務端能夠接收的速率、客戶端重連策略等），能夠極大程度保障升級過程的平滑，有效防止服務端過載，減少業務感知，從而提升服務的穩定性。

> 注：由於升級後的叢集，三個節點負載較平均，因此上圖三條線重疊在了一起。

## 結語

透過採用節點疏散功能結合模擬藍綠髮布，本文所提供的方案解決了普通升級導致的多次斷連和可能的服務過載與負載不均問題，實現了在 Kubernetes 上優雅的升級。

作為一個自動化管理工具，EMQX Kubernetes Operator 旨在幫助使用者輕鬆建立和管理 EMQX 叢集，充分享受 EMQX 的強大產品能力。透過本文方案完成 EMQX 的升級，使用者可以進一步體驗 EMQX 的最新特性，構建創新物聯網應用。

>版權宣告： 本文為 EMQ 原創，轉載請註明出處。
>
>原文連結：[https://www.emqx.com/zh/blog/how-to-upgrade-emqx-in-kubernetes](https://www.emqx.com/zh/blog/how-to-upgrade-emqx-in-kubernetes)

EMQX 在 Kubernetes 中如何進行優雅升級

相關文章