在 Kubernetes 環(huán)境下如何優(yōu)雅擴縮容 Pulsar
背景
在整個大環(huán)境的降本增效的熏陶下，我們也不得不做好應(yīng)對方案。
根據(jù)對線上流量、存儲以及系統(tǒng)資源的占用，發(fā)現(xiàn)我們的 Pulsar 集群有許多的冗余，所以考慮進行縮容從而減少資源浪費，最終也能省一些費用。
不過在縮容之前很有必要先聊聊擴容，Pulsar 一開始就是存算分離的架構(gòu)（更多關(guān)于 Pulsar 架構(gòu)的內(nèi)容本文不做過多介紹，感興趣的可以自行搜索），天然就非常適合 kubernetes 環(huán)境，也可以利用 kubernetes 的能力進行快速擴容。
擴容
Pulsar 的擴容相對比較簡單，在 kubernetes 環(huán)境下只需要修改副本即可。
Broker
當我們的 broker 層出現(xiàn)瓶頸時（比如 CPU、內(nèi)存負載較高、GC 頻繁時）可以考慮擴容。
計算層都擴容了，也需要根據(jù)流量計算下存儲層是否夠用。
如果我們使用的是 helm 安裝的 Pulsar 集群，那只需要修改對于的副本數(shù)即可。
broker:
configuration
component: broker
replicaCount: 3->5當我們將副本數(shù)從 3 增加到 5 之后 kubernetes 會自動拉起新增的兩個 Pod，之后我們啥也不需要做了。
Pulsar 的負載均衡器會自動感知到新增兩個 broker 的加入，從而幫我們將一些負載高的節(jié)點的流量遷移到新增的節(jié)點中。
Bookkeeper
在介紹 bookkeeper 擴容前先簡單介紹些 Bookkeeper 的一些基本概念。
- Ensemble size (E)：當前 Bookkeeper 集群的節(jié)點數(shù)量
- Write quorum size (QW)：一條消息需要寫入到幾個 Bookkeeper 節(jié)點中
- ACK quorum size (QA)：有多少個 Bookkeeper 節(jié)點 ACK 之后表示寫入成功
對應(yīng)到我們在 broker.conf 中的配置如下：
managedLedgerDefaultEnsembleSize: "2"
managedLedgerDefaultWriteQuorum: "2"
managedLedgerDefaultAckQuorum: "2"這個三個參數(shù)表示一條消息需要同時寫入兩個 Bookkeeper 節(jié)點，同時都返回 ACK 之后才能表示當前消息寫入成功。
從這個配置也可以看出，Bookkeeper 是多副本寫入模型，適當?shù)慕档?QW 和 QA 的數(shù)量可以提高寫入吞吐率。
大部分場景下 Bookkeeper 有三個節(jié)點然后 E/QW/QA 都配置為 2 就可以滿足消息多副本寫入了。
多副本可以保證當某個節(jié)點宕機后，這個節(jié)點的消息在其他節(jié)點依然有存放，消息讀取不會出現(xiàn)問題。
那什么情況下需要擴容 Bookkeeper 了，當然如果單個 Bookkeeper 的負載較高也是可以擴容的。
但我們當時擴容 Bookkeeper 的場景是想利用 Pulsar 的資源隔離功能。
因為有部分業(yè)務(wù)的消息量明顯比高于其他的 topic，這樣會導致某個 Broker 的負載較高，同時也可能影響到其他正常的 topic。
最好的方式就將這部分數(shù)據(jù)用單獨的 broker 和 Bookkeeper 來承載，從而實現(xiàn)硬件資源的隔離。
這樣的需求如果使用其他消息隊列往往不太好實現(xiàn)，到后來可能就會部署多個集群來實現(xiàn)隔離，但這樣也會增加運維的復雜度。
好在 Pulsar 天然就支持資源隔離，只需要一個集群就可以實現(xiàn)不同 namespace 的流量隔離。
此時就可以額外擴容幾個 Bookkeeper 節(jié)點用于特定的 namespace 使用。
圖片
從上圖可以看到：我們可以將 broker 和 Bookkeeper 分別進行分組，然后再配置對應(yīng)的 namespace，這樣就能實現(xiàn)資源隔離了。
更多關(guān)于資源隔離的細節(jié)本文就不過多贅述了。
鋪墊了這么多，其實 Bookkeeper 的擴容也蠻簡單的：
bookkeeper:
component: bookie
metadata:
resources:
# requests:
# memory: 4Gi
# cpu: 2
replicaCount: 3->5和 broker 擴容類似，提高副本數(shù)量后，Pulsar 的元數(shù)據(jù)中心會感知到新的 Bookkeeper 節(jié)點加入，從而更新 broker 中的節(jié)點數(shù)據(jù)，這樣就會根據(jù)我們配置的隔離策略分配流量。
縮容
其實本文的重點在于縮容，特別是 Bookkeeper 的縮容，這部分內(nèi)容我在互聯(lián)網(wǎng)上很少看到有人提及。
Broker
Broker 的縮容相對簡單，因為存算分離的特點：broker 作為計算層是無狀態(tài)的，并不承載任何的數(shù)據(jù)。
其實是承載數(shù)據(jù)的，只是 Pulsar 會自動遷移數(shù)據(jù)，從而體感上覺得是無狀態(tài)的。
只是當一個 broker 下線后，它上面所綁定的 topic 會自動轉(zhuǎn)移到其他在線的 broker 中。
這個過程會導致連接了這個 broker 的 client 觸發(fā)重連，從而短暫的影響業(yè)務(wù)。
正因為 broker 的下線會導致 topic 的歸屬發(fā)生轉(zhuǎn)移，所以在下線前最好是先通過監(jiān)控面板觀察需要下線的 broker topic 是否過多，如果過多則可以先手動 unload 一些數(shù)據(jù)，盡量避免一次性大批量的數(shù)據(jù)轉(zhuǎn)移。
圖片
觀察各個broker 的 topic 數(shù)量
Bookkeeper
而 Bookkeeper 的縮容則沒那么容易了，由于它是作為存儲層，本身是有狀態(tài)的，下線后節(jié)點上存儲的數(shù)據(jù)是需要遷移到其他的 Bookkeeper 節(jié)點中的。
不然就無法滿足之前提到的 Write quorum size (QW) 要求；因此縮容還有一個潛在條件需要滿足：
縮容后的 Bookkeeper 節(jié)點數(shù)量需要大于broker 中的配置：
managedLedgerDefaultEnsembleSize: "2"
managedLedgerDefaultWriteQuorum: "2"
managedLedgerDefaultAckQuorum: "2"不然寫入會失敗，整個集群將變得不可用。
Pulsar 提供了兩種 Bookkeeper 的下線方案：
不需要遷移數(shù)據(jù)
其實兩種方案主要區(qū)別在于是否需要遷移數(shù)據(jù)，第一種比較簡單，就是不遷移數(shù)據(jù)的方案。
首先需要將 Bookkeeper 設(shè)置為 read-only 狀態(tài)，此時該節(jié)點將不會接受寫請求，直到這個 Bookkeeper 上的數(shù)據(jù)全部過期被回收后，我們就可以手動下線該節(jié)點。
使用 forceReadOnlyBookie=true 可以強制將 Bookkeeper 設(shè)置為只讀。
但這個方案存在幾個問題：
- 下線時間不確定，如果該 Bookkeeper 上存儲的數(shù)據(jù)生命周期較長，則無法預估什么時候可以下線該節(jié)點。
- 該配置修改后需要重啟才能生效，在 kubernetes 環(huán)境中這些配置都是寫在了 configmap 中，一旦刷新后所有節(jié)點都會讀取到該配置，無法針對某一個節(jié)點生效；所以可能會出現(xiàn)將不該下線的節(jié)點設(shè)置為了只讀狀態(tài)。
但該方案的好處是不需要遷移數(shù)據(jù)，人工介入的流程少，同樣也就減少了出錯的可能。
比較適合于用虛擬機部署的集群。
遷移數(shù)據(jù)
第二種就是需要遷移數(shù)據(jù)的方案，更適用于 kubernetes 環(huán)境。
遷移原理
先來看看遷移的原理：
- 當 bookkeeper 停機后，AutoRecovery Auditor 會檢測到 zookeeper 節(jié)點/ledger/available 發(fā)生變化，將下線節(jié)點的 ledger 信息寫入到 zookeeper 的 /ledgers/underreplicated 節(jié)點中。
- AutoRecovery ReplicationWorker 會檢測 /ledgers/underreplicated節(jié)點信息，然后輪訓這些 ledger 信息從其他在線的 BK 中復制數(shù)據(jù)到?jīng)]有該數(shù)據(jù)的節(jié)點，保證 QW 數(shù)量不變。
每復制一條數(shù)據(jù)后都會刪除 /ledgers/underreplicated 節(jié)點信息。
所有 /ledgers/underreplicated 被刪除后說明遷移任務(wù)完成。
- 執(zhí)行 bin/bookkeeper shell decommissionbookie 下線命令：
- 會等待 /ledgers/underreplicated 全部刪除
- 然后刪除 zookeeper 中的元數(shù)據(jù)
- 元數(shù)據(jù)刪除后 bookkeeper 才是真正下線成功，此時 broker 才會感知到 Bookkeeper 下線。
AutoRecovery 是 Bookkeeper 提供的一個自動恢復程序，他會在后臺檢測是否有數(shù)據(jù)需要遷移。
簡單來說就是當某個Bookkeeper 停機后，它上面所存儲的 ledgerID 會被寫入到元數(shù)據(jù)中心，此時會有一個單獨的線程來掃描這些需要遷移的數(shù)據(jù)，最終將這些數(shù)據(jù)寫入到其他在線的 Bookkeeper 節(jié)點。
Bookkeeper 中的一些關(guān)鍵代碼：
圖片
圖片
下線步驟
下面來看具體的下線流程：
- 副本數(shù)-1
bin/bookkeeper shell listunderreplicated 檢測有多少 ledger 需要被遷移
- 執(zhí)行遠程下線元數(shù)據(jù)
- nohup bin/bookkeeper shell decommissionbookie -bookieid bkid:3181 > bk.log 2>&1 &
- 這個命令會一直后臺運行等待數(shù)據(jù)遷移完成，比較耗時
- 查看下線節(jié)點是否已被剔除
- bin/bookkeeper shell listbookies -a
- 循環(huán)第一步
第一步是檢測一些現(xiàn)在有多少數(shù)據(jù)需要遷移：bin/bookkeeper shell listunderreplicated 命令查看需要被遷移的 ledger 數(shù)據(jù)也是來自于 /ledgers/underreplicated節(jié)點
圖片
正常情況下是 0
第二步的命令會等待數(shù)據(jù)遷移完成后從 zookeeper 中刪除節(jié)點信息，這個進程退出后表示下線成功。
圖片
這個命令最好是后臺執(zhí)行，并輸出日志到專門的文件，因為周期較長，很有可能終端會話已經(jīng)超時了。
我們登錄 zookeeper 可以看到需要遷移的 ledger 數(shù)據(jù)：
bin/pulsar zookeeper-shell -server pulsar-zookeeper:2181
get /ledgers/underreplication/ledgers/0000/0000/0000/0002/urL0000000002
replica: "pulsar-test-2-bookie-0.pulsar-test-2-bookie.pulsar-test-2.svc.cluster.local:3181"
ctime: 1708507296519underreplication 的節(jié)點路徑中存放了 ledgerId，通過 ledgerId 計算路徑：
圖片
圖片
注意事項
下線過程中我們可以查看 nohup bin/bookkeeper shell decommissionbookie -bookieid bkid:3181 > bk.log 2>&1 &這個命令寫入的日志來確認遷移的進度，日志中會打印當前還有多少數(shù)量的 ledger 沒有遷移。
同時需要觀察 zookeeper、Bookkeeper 的資源占用情況。
因為遷移過程中寫入大量數(shù)據(jù)到 zookeeper 節(jié)點，同時遷移數(shù)時也會有大量流量寫入 Bookkeeper。
不要讓遷移過程影響到了正常的業(yè)務(wù)使用。
根據(jù)我的遷移經(jīng)驗來看，通常 2w 的ledger 數(shù)據(jù)需要 2～3 小時不等的時間，具體情況還得根據(jù)你的集群來確認。
回滾方案
當然萬一遷移比較耗時，或者影響了業(yè)務(wù)使用，所以還是要有一個回滾方案：
這里有一個大的前提：只要 BK 節(jié)點元數(shù)據(jù)、PVC（也就是磁盤中的數(shù)據(jù)） 沒有被刪除就可以進行回滾。
所以只要上述的 decommissionbookie 命令沒有完全執(zhí)行完畢，我們就可以手動 kill 該進程，然后恢復副本數(shù)據(jù)。
這樣恢復的 Bookkeeper 節(jié)點依然可以提供服務(wù)，同時數(shù)據(jù)也還存在；只是浪費了一些 autorecovery 的資源。
最后當 bookkeeper 成功下線后，我們需要刪除 PVC，不然如果今后需要擴容的時候是無法啟動 bookkeeper 的，因為在啟動過程中會判斷掛載的磁盤是否有數(shù)據(jù)。
總結(jié)
總的來說 Pulsar 的擴縮容還是非常簡單的，只是對于有狀態(tài)節(jié)點的數(shù)據(jù)遷移稍微復雜一些，但只要跟著流程走就不會有什么問題。
參考鏈接：
