背景

為了降低 EMQX 在 Kubernetes 上的部署、運(yùn)維成本，我們將一些日常運(yùn)維能力進(jìn)行總結(jié)、抽象并整合到代碼中，以 EMQX Kubernetes Operator 的方式幫助用戶實(shí)現(xiàn) EMQX 的自動(dòng)化部署和運(yùn)維。

此前，EMQX Kubernetes Operator v1beta1、v1beta2、v1beta3 的升級(jí)策略均為滾動(dòng)升級(jí)，相關(guān)升級(jí)流程如下:

問(wèn)題分析

滾動(dòng)升級(jí)在生產(chǎn)環(huán)境中可能會(huì)面臨以下問(wèn)題：

• 升級(jí)過(guò)程中會(huì)逐個(gè)銷毀舊的節(jié)點(diǎn)再創(chuàng)建新的節(jié)點(diǎn)，因此可能導(dǎo)致客戶端多次斷連（最糟糕的情況下斷連次數(shù)與節(jié)點(diǎn)數(shù)量一致），從而影響用戶體驗(yàn)。

• 當(dāng)集群處于較高連接的情況下，一個(gè)節(jié)點(diǎn)被銷毀，那么該節(jié)點(diǎn)上面的連接會(huì)在瞬間斷開(kāi)，由客戶端重試邏輯來(lái)進(jìn)行重連；當(dāng)單節(jié)點(diǎn)連接數(shù)較大時(shí)，如果大量客戶端進(jìn)行重連，則可能會(huì)給服務(wù)端造成壓力導(dǎo)致過(guò)載。

• 升級(jí)完成后，各節(jié)點(diǎn)間的負(fù)載不均衡（如上圖：emqx-ee-0 在升級(jí)過(guò)程中，客戶端可能會(huì)進(jìn)行重連，此時(shí)由于 emqx-ee-0 還未就緒，因此可能連接到 emqx-ee-1 或者 emqx-ee-2，升級(jí)完成后 emqx-ee-0 上可能只有較少負(fù)載或者無(wú)負(fù)載），從而打破業(yè)務(wù)容量模型的規(guī)劃，可能影響到服務(wù)。

• 由于使用 StatefulSets 進(jìn)行部署，在升級(jí)過(guò)程中提供服務(wù)的節(jié)點(diǎn)會(huì)比實(shí)際節(jié)點(diǎn)要少一個(gè)（影響到用戶的業(yè)務(wù)模型），這可能會(huì)增加服務(wù)端的一些壓力。

如果上面幾個(gè)步驟的問(wèn)題疊加（多次斷連與大量斷連的客戶端不停的重試連接），則可能會(huì)放大客戶端重連的規(guī)模，從而造成服務(wù)端過(guò)載或雪崩。

下圖是在現(xiàn)有升級(jí)模式下連接數(shù)的監(jiān)控圖（在不同的業(yè)務(wù)中會(huì)存在差異，比如后端依賴的不同資源、服務(wù)器配置、客戶端重連或重試策略等，均會(huì)帶來(lái)一些不同的影響）。其中：

• sum：總的連接數(shù)，圖中最上面的一條線

• emqx-ee-a：前綴表示的是升級(jí)前 3 個(gè) EMQX 節(jié)點(diǎn)

• emqx-ee-b：前綴表示的是升級(jí)后 3 個(gè) EMQX 節(jié)點(diǎn)

在上圖中，當(dāng)我們開(kāi)始執(zhí)行滾動(dòng)升級(jí)時(shí)，首先 emqx-ee-a-emqx-ee-2 進(jìn)行銷毀，并創(chuàng)建新的 emqx-ee-b-emqx-ee-2，此時(shí)僅有 emqx-ee-a-emqx-ee-1、emqx-ee-a-emqx-ee-0 能夠提供服務(wù)，當(dāng)客戶端進(jìn)行重連時(shí)，LB 會(huì)將流量轉(zhuǎn)移到 emqx-ee-a-emqx-ee-0、emqx-ee-a-emqx-ee-1 上面，因此我們能夠看到 emqx-ee-a-emqx-ee-1、emqx-ee-a-emqx-ee-0 有明顯的流量上升，當(dāng)后面更新這兩個(gè) pod 時(shí)，意味著客戶端可能多次斷連。由于新 pod 建立的過(guò)程存在著時(shí)間差，以上圖為例，emqx-ee-a-emqx-ee-0 最后升級(jí)，當(dāng)升級(jí)完成后，可能客戶端已經(jīng)完成重試、重連，此時(shí)主要連接已經(jīng)被另兩個(gè) pod 接納，因此會(huì)導(dǎo)致 pod 之間流量不均衡，從而影響到用戶業(yè)務(wù)模型的評(píng)估，或者影響到服務(wù)。

為了方便展示，我們未壓測(cè)大量連接模擬重連、導(dǎo)致服務(wù)端過(guò)載的場(chǎng)景（在實(shí)際生產(chǎn)環(huán)境中可能遇到，TPS 超過(guò)云端規(guī)劃的容量模型），但從連接數(shù)監(jiān)控圖上，我們依然看到一個(gè)大缺口，說(shuō)明對(duì)業(yè)務(wù)產(chǎn)生了較大影響。因此我們需制定一種方案來(lái)規(guī)避以上幾個(gè)問(wèn)題，保障升級(jí)過(guò)程中的平滑穩(wěn)定。

問(wèn)題解決

目標(biāo)

• 升級(jí)過(guò)程中實(shí)現(xiàn)連接數(shù)可控遷移（可根據(jù)服務(wù)端處理能力設(shè)置相應(yīng)的遷移速率）。

• 升級(jí)過(guò)程中減少連接斷開(kāi)的次數(shù)（一次斷連）。

• 在整個(gè)升級(jí)的過(guò)程中始終保持預(yù)期的節(jié)點(diǎn)來(lái)提供服務(wù)。

• 升級(jí)完成后，不需要集群負(fù)載重平衡，各節(jié)點(diǎn)間的連接相對(duì)均衡（與 LB 調(diào)度策略有一定關(guān)系）。

方案設(shè)計(jì)

藍(lán)綠發(fā)布是一種同時(shí)運(yùn)行兩個(gè)版本應(yīng)用的發(fā)布策略。EMQX Kubernetes Operator 近日在 2.1.0 版本中實(shí)現(xiàn)了 EMQX Enterprise 的藍(lán)綠發(fā)布，即從現(xiàn)有的 EMQX Enterprise 集群開(kāi)始，創(chuàng)建一套新版本的 EMQX Enterprise 集群，在這一過(guò)程中不停止掉老版本，等新版本集群運(yùn)行起來(lái)后，再將流量逐步平滑切換到新版本上。

從 4.4.12 版本開(kāi)始，EMQX 企業(yè)版本支持節(jié)點(diǎn)疏散功能。節(jié)點(diǎn)疏散功能允許用戶在關(guān)閉節(jié)點(diǎn)之前強(qiáng)制將連接和會(huì)話以一定速率遷移到其他節(jié)點(diǎn)，以避免節(jié)點(diǎn)關(guān)閉帶來(lái)的會(huì)話數(shù)據(jù)丟失。

關(guān)于節(jié)點(diǎn)疏散更多信息請(qǐng)參考相關(guān)文檔

在 Kubernetes 上我們通過(guò)模擬藍(lán)綠發(fā)布以及結(jié)合節(jié)點(diǎn)疏散功能，實(shí)現(xiàn)了連接可控遷移，極大減少了斷連的次數(shù)（僅斷連一次）。相關(guān)升級(jí)流程圖如下：

整個(gè)升級(jí)流程大致可分為以下幾步:

• 升級(jí)時(shí)（鏡像、Pod 相關(guān)資源修改調(diào)整）我們會(huì)先創(chuàng)建一個(gè)同規(guī)格的節(jié)點(diǎn)加入到現(xiàn)有集群中。

• 當(dāng)新節(jié)點(diǎn)全部就緒后，我們將 service 全部指向新創(chuàng)建的節(jié)點(diǎn)，此時(shí)新節(jié)點(diǎn)開(kāi)始接受新的連接請(qǐng)求。

• 將舊節(jié)點(diǎn)從 service 中摘出，此時(shí)舊節(jié)點(diǎn)不再接收新的連接請(qǐng)求。

• 通過(guò) EMQX 節(jié)點(diǎn)疏散功能，逐個(gè)對(duì)節(jié)點(diǎn)上的連接進(jìn)行可控遷移，直至連接全部完成遷移，再對(duì)節(jié)點(diǎn)進(jìn)行銷毀。

操作流程

節(jié)點(diǎn)疏散是 EMQX Enterprise 4.4.12 開(kāi)始支持的新特性，EMQX Kubernetes Operator 在 2.1 版本中對(duì)該能力進(jìn)行適配，如需使用該能力，請(qǐng)將 EMQX 升級(jí)到企業(yè)版 v4.4.12，EMQX Kubernetes Operator 升級(jí)到 v2.1。

• 配置藍(lán)綠升級(jí)

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

initialDelaySeconds：所有的節(jié)點(diǎn)就緒后（藍(lán)綠節(jié)點(diǎn)），開(kāi)始節(jié)點(diǎn)疏散前的等待時(shí)間 （由于切換 Service 后，LoadBalancer 需要時(shí)間來(lái)處理 service 與 pod 的關(guān)系）（單位：秒）

waitTakeover：所有連接斷開(kāi)后，等待客戶端重連以接管會(huì)話的時(shí)間（單位：秒）

connEvictRate：客戶端每秒斷開(kāi)連接速度

sessEvictRate：waitTakeover之后每秒會(huì)話疏散速度

詳情可參考：Operator 文檔

升級(jí)過(guò)程中連接數(shù)監(jiān)控圖如下（本次測(cè)試以 10 萬(wàn)連接進(jìn)行）：

sum：總的連接數(shù)，圖中最上面的一條線

emqx-ee-86d7758868：前綴表示的是升級(jí)前的 3 個(gè) EMQX 節(jié)點(diǎn)

emqx-ee-745858464d：前綴表示升級(jí)后的 3 個(gè) EMQX 節(jié)點(diǎn)

如上圖，我們通過(guò) EMQX Kubernetes Operator 的藍(lán)綠發(fā)布在 Kubernetes 中實(shí)現(xiàn)了優(yōu)雅升級(jí)，通過(guò)該方案升級(jí)，總連接數(shù)未出現(xiàn)較大抖動(dòng)（取決于遷移速率、服務(wù)端能夠接收的速率、客戶端重連策略等），能夠極大程度保障升級(jí)過(guò)程的平滑，有效防止服務(wù)端過(guò)載，減少業(yè)務(wù)感知，從而提升服務(wù)的穩(wěn)定性。

注：由于升級(jí)后的集群，三個(gè)節(jié)點(diǎn)負(fù)載較平均，因此上圖三條線重疊在了一起。

結(jié)語(yǔ)

通過(guò)采用節(jié)點(diǎn)疏散功能結(jié)合模擬藍(lán)綠發(fā)布，本文所提供的方案解決了普通升級(jí)導(dǎo)致的多次斷連和可能的服務(wù)過(guò)載與負(fù)載不均問(wèn)題，實(shí)現(xiàn)了在 Kubernetes 上優(yōu)雅的升級(jí)。

作為一個(gè)自動(dòng)化管理工具，EMQX Kubernetes Operator 旨在幫助用戶輕松創(chuàng)建和管理 EMQX 集群，充分享受 EMQX 的強(qiáng)大產(chǎn)品能力。通過(guò)本文方案完成 EMQX 的升級(jí)，用戶可以進(jìn)一步體驗(yàn) EMQX 的最新特性，構(gòu)建創(chuàng)新物聯(lián)網(wǎng)應(yīng)用。

版權(quán)聲明： 本文為 EMQ 原創(chuàng)，轉(zhuǎn)載請(qǐng)注明出處。

原文鏈接：https://www./zh/blog/how-to-upgrade-emqx-in-kubernetes