螞蟻集團(tuán)運維著可能是全球最大的 k8s 集群：k8s 官方以 5k node 作為 k8s 規(guī)模化的頂峰，而螞蟻集團(tuán)事實上運維著規(guī)模達(dá)到 10k node 規(guī)模的 k8s 集群。一個形象的比喻就是，如果官方以及跟著官方的 k8s 使用者能想象到的 k8s 的集群規(guī)模是泰山，那么螞蟻集團(tuán)在官方的解決方案之上已經(jīng)實現(xiàn)了一個珠穆朗瑪峰，引領(lǐng)了 k8s 規(guī)模化技術(shù)的提升。?

這個量級的差異，不僅僅是量的差異，更是 k8s 管理維護(hù)的質(zhì)的提升。能維護(hù)有如此巨大挑戰(zhàn)巨量規(guī)模的 k8s 集群，其背后原因是螞蟻集團(tuán)付出了遠(yuǎn)大于 k8s 官方的優(yōu)化努力。

所謂萬丈高樓平地起，本文著重討論下螞蟻集團(tuán)的在 k8s 的基石?--- etcd 層面做出的高可用建設(shè)工作：只有 etcd 這個基石穩(wěn)當(dāng)了，k8s 這棟高樓大廈才保持穩(wěn)定性，有 tidb 大佬黃東旭朋友圈佐證【圖片已獲黃總授權(quán)】。

面臨的挑戰(zhàn)

etcd 首先是 k8s 集群的 KV 數(shù)據(jù)庫。?

從數(shù)據(jù)庫的角度來看，k8s 整體集群架構(gòu)各個角色如下：

• etcd?集群的數(shù)據(jù)庫

• kube-apiserver?etcd?的?API?接口代理、數(shù)據(jù)緩存層

• kubelet?數(shù)據(jù)的生產(chǎn)者和消費者

• kube-controller-manager?數(shù)據(jù)的消費者和生產(chǎn)者

• kube-scheduler?數(shù)據(jù)的消費者和生產(chǎn)者

etcd 本質(zhì)是一個 KV 數(shù)據(jù)庫，存儲了 k8s 自身資源 、用戶自定義的 CRD 以及 k8s 系統(tǒng)的 event 等數(shù)據(jù)。每種數(shù)據(jù)的一致性和數(shù)據(jù)安全性要求不一致，如 event 數(shù)據(jù)的安全性小于 k8s 自身的資源數(shù)據(jù)以及 CRD 數(shù)據(jù)。

k8s 的早期擁護(hù)者在推廣 k8s 時，宣稱其比 OpenStack 的優(yōu)勢之一是 k8s 沒有使用消息隊列，其延遲比 OpenStack 低。這其實是一個誤解，無論是 etcd 提供的 watch 接口，還是 k8s client 包中的 informer 機(jī)制，無不表明 k8s 是把 etcd 當(dāng)做了消息隊列，k8s 消息的載體很多，譬如 k8s event。

從消息隊列的角度來看，k8s 整體集群架構(gòu)各個角色如下：

• etcd?消息路由器

• kube-apiserver?etcd?生產(chǎn)者消息代理和消息廣播【或者成為次級消息路由器、消費者代理】

• kubelet?消息的生產(chǎn)者和消費者

• kube-controller-manager?消息的消費者和生產(chǎn)者

• kube-scheduler?消息的消費者和生產(chǎn)者

etcd 是推模式的消息隊列。etcd 是 k8s 集群的 KV 數(shù)據(jù)庫和消息路由器，充當(dāng)了 OpenStack 集群中的 MySQL 和 MQ 兩個角色，這樣的實現(xiàn)貌似簡化了集群的結(jié)構(gòu)，但其實不然。在 large scale 規(guī)模 k8s 集群中，一般經(jīng)驗，首先都會使用一個單獨 etcd 集群存儲 event 數(shù)據(jù)：把 KV 數(shù)據(jù)和一部分 MQ 數(shù)據(jù)物理隔離開，實現(xiàn)了 KV 和 MQ 角色的部分分離。?如?參考文檔 2 中提到美團(tuán)?“針對 etcd 的運營，通過拆分出獨立的 event 集群降低主庫的壓力”。

當(dāng) k8s 集群規(guī)模擴(kuò)大時，etcd 承載著 KV 數(shù)據(jù)劇增、event 消息暴增以及消息寫放大的三種壓力。為了證明所言非虛，特引用部分?jǐn)?shù)據(jù)為佐證：

• etcd KV 數(shù)據(jù)量級在 100 萬以上；

• etcd event 數(shù)據(jù)量在 10 萬以上；

• etcd 讀流量壓力峰值在 30 萬 pqm 以上，其中讀 event 在 10k qpm 以上；

• etcd 寫流量壓力峰值在 20 萬 pqm 以上，其中寫 event 在 15k qpm 以上；

• etcd CPU 經(jīng)常性飆升到 900%?以上；

• etcd 內(nèi)存 RSS 在 60 GiB 以上；

• etcd 磁盤使用量可達(dá) 100 GiB 以上；

• etcd 自身的 goroutine 數(shù)量 9k 以上；

• etcd 使用的用戶態(tài)線程達(dá) 1.6k 以上；

• etcd gc 單次耗時常態(tài)下可達(dá) 15ms。

使用 Go 語言實現(xiàn)的 etcd 管理這些數(shù)據(jù)非常吃力，無論是 CPU、內(nèi)存、gc、goroutine 數(shù)量還是線程使用量，基本上都接近 go runtime 管理能力極限：經(jīng)常在 CPU profile 中觀測到 go runtime 和 gc 占用資源超過 50%?以上。

螞蟻的 k8s 集群在經(jīng)歷高可用項目維護(hù)之前，當(dāng)集群規(guī)模突破 7 千節(jié)點規(guī)模時，曾出現(xiàn)如下性能瓶頸問題：

• etcd 出現(xiàn)大量的讀寫延遲，延遲甚至可達(dá)分鐘級；

• kube-apiserver 查詢 pods / nodes / configmap / crd 延時很高，導(dǎo)致 etcd oom；

• etcd list-all pods 時長可達(dá) 30?分鐘以上；

• 2020 年 etcd 集群曾因 list-all 壓力被打垮導(dǎo)致的事故就達(dá)好幾起；

• 控制器無法及時感知數(shù)據(jù)變化，如出現(xiàn) watch 數(shù)據(jù)延遲可達(dá) 30s 以上。

如果說這種狀況下的 etcd 集群是在刀鋒上跳舞，?此時的整個 k8s 集群就是一個活火山：稍不留神就有可能背個 P 級故障，?彼時的整個 k8s master 運維工作大概是整個螞蟻集團(tuán)最危險的工種之一。

高可用策略

實現(xiàn)一個分布式系統(tǒng)高可用能力的提升，大概有如下手段：

• 提升自身穩(wěn)定性與性能；

• 精細(xì)管理上游流量；

• 保證服務(wù)下游服務(wù) SLO。

etcd 經(jīng)過社區(qū)與各方使用者這么多年的錘煉，其自身的穩(wěn)定性足夠。螞蟻人能做到的，無非是使出周扒皮的本事，提高集群資源整體利用率，scale out 和 scale up 兩種技術(shù)手段雙管齊下，盡可能的提升其性能。

etcd 自身作為 k8s 的基石，其并無下游服務(wù)。如果說有，那也是其自身所使用的物理 node 環(huán)境了。下面分別從 etcd 集群性能提升、請求流量管理等角度闡述我們在 etcd 層面所做出的高可用能力提升工作。

文件系統(tǒng)升級

在山窩里飛出金鳳凰，誠非易事。讓 etcd 跑的更快這件事，沒有什么手段比提供一個高性能的機(jī)器更短平快地見效了。?

1.使用 NVMe?ssd

etcd 自身?= etcd 程序?+?其運行環(huán)境。早期 etcd 服務(wù)器使用的磁盤是 SATA 盤，經(jīng)過簡單地測試發(fā)現(xiàn) etcd 讀磁盤速率非常慢，老板豪橫地把機(jī)器鳥槍換炮?---?升級到使用了 NVMe SSD 的 f53 規(guī)格的機(jī)器：etcd 使用 NVMe ssd 存儲 boltdb 數(shù)據(jù)后，隨機(jī)寫速率可提升到 70 MiB/s 以上。

參考文檔 2 中提到美團(tuán)?“基于高配的 SSD 物理機(jī)器部署可以達(dá)到日常 5 倍的高流量訪問”，可見提升硬件性能是大廠的首選，能折騰機(jī)器千萬別浪費人力。

2.使用?tmpfs?

NVMe ssd 雖好，理論上其讀寫極限性能跟內(nèi)存比還是差一個數(shù)量級。我們測試發(fā)現(xiàn)使用 tmpfs【未禁止 swap out】替換 NVMe ssd 后，etcd 在讀寫并發(fā)的情況下性能仍然能提升 20%?之多。考察 k8s 各種數(shù)據(jù)類型的特點后，考慮到 event 對數(shù)據(jù)的安全性要求不高但是對實時性要求較高的特點，我們毫不猶豫的把 event etcd 集群運行在了 tmpfs 文件系統(tǒng)之上，將 k8s 整體的性能提升了一個層次。?

3.磁盤文件系統(tǒng)

磁盤存儲介質(zhì)升級后，存儲層面能夠進(jìn)一步做的事情就是研究磁盤的文件系統(tǒng)格式。目前 etcd 使用的底層文件系統(tǒng)是 ext4 格式，其 block size 使用的是默認(rèn)的 4 KiB。我們團(tuán)隊曾對 etcd 進(jìn)行單純的在單純寫并行壓測時發(fā)現(xiàn)，把文件系統(tǒng)升級為 xfs，且 block size 為 16 KiB【在測試的 KV size 總和 10 KiB 條件下】時，etcd 的寫性能仍然有提升空間。

但在讀寫并發(fā)的情況下，磁盤本身的寫隊列幾乎毫無壓力，又由于 etcd 3.4 版本實現(xiàn)了并行緩存讀，磁盤的讀壓力幾乎為零，這就意味著：繼續(xù)優(yōu)化文件系統(tǒng)對 etcd 的性能提升空間幾乎毫無幫助。自此以后單節(jié)點 etcd scale up 的關(guān)鍵就從磁盤轉(zhuǎn)移到了內(nèi)存：優(yōu)化其內(nèi)存索引讀寫速度。

4.磁盤透明大頁

在現(xiàn)代操作系統(tǒng)的內(nèi)存管理中，有 huge page 和 transparent huge page 兩種技術(shù)，不過一般用戶采用 transparent huge page 實現(xiàn)內(nèi)存 page 的動態(tài)管理。在 etcd 運行環(huán)境，關(guān)閉 transparent huge page 功能，否則 RT 以及 QPS 等經(jīng)常性的監(jiān)控指標(biāo)會經(jīng)常性的出現(xiàn)很多毛刺，導(dǎo)致性能不平穩(wěn)。

etcd?調(diào)參

MySQL 運維工程師常被人稱為?“調(diào)參工程師”，另一個有名的 KV 數(shù)據(jù)庫 RocksDB 也不遑多讓，二者可調(diào)整的參數(shù)之多到了令人發(fā)指的地方：其關(guān)鍵就在于針對不同存儲和運行環(huán)境需要使用不同的參數(shù)，才能充分利用硬件的性能。etcd 隨不及之，但也不拉人后，預(yù)計以后其可調(diào)整參數(shù)也會越來越多。

etcd 自身也對外暴露了很多參數(shù)調(diào)整接口。除了阿里集團(tuán) k8s 團(tuán)隊曾經(jīng)做出的把 freelist 由 list 改進(jìn)為 map 組織形式優(yōu)化外，目前常規(guī)的 etcd 可調(diào)整參數(shù)如下：

• write batch

• compaction

1.write?batch

像其他常規(guī)的 DB 一樣，etcd 磁盤提交數(shù)據(jù)時也采用了定時批量提交、異步寫盤的方式提升吞吐，并通過內(nèi)存緩存的方式平衡其延時。具體的調(diào)整參數(shù)接口如下：

• batch write number 批量寫 KV 數(shù)目，默認(rèn)值是 10k；

• batch write interval 批量寫事件間隔，默認(rèn)值是 100 ms。

etcd batch 這兩個默認(rèn)值在大規(guī)模 k8s 集群下是不合適的，需要針對具體的運行環(huán)境調(diào)整之，避免導(dǎo)致內(nèi)存使用 OOM。一般地規(guī)律是，集群 node 數(shù)目越多，這兩個值就應(yīng)該成比例減小。

2.compaction

etcd 自身由于支持事務(wù)和消息通知，所以采用了 MVCC 機(jī)制保存了一個 key 的多版本數(shù)據(jù)，etcd 使用定時的 compaction 機(jī)制回收這些過時數(shù)據(jù)。etcd 對外提供的壓縮任務(wù)參數(shù)如下：

• compaction interval 壓縮任務(wù)周期時長；

• compaction sleep interval 單次壓縮批次間隔時長，默認(rèn) 10 ms；

• compaction batch limit 單次壓縮批次 KV 數(shù)目，默認(rèn) 1000。

（1）壓縮任務(wù)周期

k8s 集群的 etcd compaction 可以有兩種途徑進(jìn)行 compaction：

• etcd 另外提供了 comapct 命令和 API 接口，k8s kube-apiserver 基于這個 API 接口也對外提供了 compact 周期參數(shù)；

• etcd 自身會周期性地執(zhí)行 compaction；

• etcd 對外提供了自身周期性 compaction 參數(shù)調(diào)整接口，這個參數(shù)的取值范圍是?(0, 1 hour]；

• 其意義是：etcd compaction 即只能打開不能關(guān)閉，如果設(shè)置的周期時長大于 1 hour，則 etcd 會截斷為 1 hour。

螞蟻 k8s 團(tuán)隊在經(jīng)過測試和線下環(huán)境驗證后，目前的壓縮周期取值經(jīng)驗是：

• 在 etcd 層面把 compaction 周期盡可能地拉長，如取值 1 hour，形同在 etcd 自身層面關(guān)閉 compaction，把 compaction interval 的精細(xì)調(diào)整權(quán)交給 k8s kube-apiserver；

• 在 k8s kube-apiserver 層面，根據(jù)線上集群規(guī)模取值不同的 compaction interval。

之所以把 etcd compaction interval 精細(xì)調(diào)整權(quán)調(diào)整到 kube-apiserver 層面，是因為 etcd 是 KV 數(shù)據(jù)庫，不方便經(jīng)常性地啟停進(jìn)行測試，而 kube-apiserver 是 etcd 的緩存，其數(shù)據(jù)是弱狀態(tài)數(shù)據(jù)，相對來說啟停比較方便，方便調(diào)參。至于 compaction interval 的取值，一條經(jīng)驗是：集群 node 越多 compaction interval 取值可以適當(dāng)調(diào)大。compaction 本質(zhì)是一次寫動作，在大規(guī)模集群中頻繁地執(zhí)行 compaction 任務(wù)會影響集群讀寫任務(wù)的延時，集群規(guī)模越大，其延時影響越明顯，在 kube-apiserver 請求耗時監(jiān)控上表現(xiàn)就是有頻繁出現(xiàn)地周期性的大毛刺。

更進(jìn)一步，如果平臺上運行的任務(wù)有很明顯的波谷波峰特性，如每天的 8:30 am ~ 21:45 pm 是業(yè)務(wù)高峰期，其他時段是業(yè)務(wù)波峰期，那么可以這樣執(zhí)行 compaction 任務(wù)：

• 在 etcd 層面設(shè)定 compaction 周期是 1 hour；

• 在 kube-apiserver 層面設(shè)定 comapction 周期是 30 minutes；

• 在 etcd 運維平臺上啟動一個周期性任務(wù)：當(dāng)前時間段在業(yè)務(wù)波谷期，則啟動一個 10 minutes 周期的 compaction 任務(wù)。

其本質(zhì)就是把 etcd compaction 任務(wù)交給 etcd 運維平臺，當(dāng)發(fā)生電商大促銷等全天無波谷的特殊長周期時間段時，就可以在平臺上緊急關(guān)閉 compaction 任務(wù)，把 compaction 任務(wù)對正常的讀寫請求影響降低到最低。

（2）單次壓縮

即使是單次壓縮任務(wù)，etcd 也是分批執(zhí)行的。因為 etcd 使用的存儲引擎 boltdb 的讀寫形式是多讀一寫：可以同時并行執(zhí)行多個讀任務(wù)，但是同時刻只能執(zhí)行一個寫任務(wù)。

為了防止單次 compaction 任務(wù)一直占用 boltdb 的讀寫鎖，每次執(zhí)行一批固定量【compaction batch limit】的磁盤 KV 壓縮任務(wù)后，etcd 會釋放讀寫鎖 sleep 一段時間【compaction sleep interval】。

在 v3.5 之前，compaction sleep interval 固定為 10 ms，在 v3.5 之后 etcd 已經(jīng)把這個參數(shù)開放出來方便大規(guī)模 k8s 集群進(jìn)行調(diào)參。類似于 batch write 的 interval 和 number，單次 compaction 的 sleep interval 和 batch limit 也需要不同的集群規(guī)模設(shè)定不同的參數(shù)，以保證 etcd 平穩(wěn)運行和 kube-apiserver 的讀寫 RT 指標(biāo)平穩(wěn)無毛刺。?

運維平臺

無論是 etcd 調(diào)參，還是升級其運行的文件系統(tǒng)，都是通過 scale up 的手段提升 etcd 的能力。還有兩種 scale up 手段尚未使用：

• 通過壓測或者在線獲取 etcd 運行 profile，分析 etcd 流程的瓶頸，然后優(yōu)化代碼流程提升性能；

• 通過其他手段降低單節(jié)點 etcd 數(shù)據(jù)量。

通過代碼流程優(yōu)化 etcd 性能，可以根據(jù) etcd 使用方的人力情況進(jìn)行之，更長期的工作應(yīng)該是緊跟社區(qū)，及時獲取其版本升級帶來的技術(shù)紅利。通過降低 etcd 數(shù)據(jù)規(guī)模來獲取 etcd 性能的提升則必須依賴 etcd 使用方自身的能力建設(shè)了。

我們曾對 etcd 的單節(jié)點 RT 與 QPS 性能與 KV 數(shù)據(jù)量的關(guān)系進(jìn)行過 benchmark 測試，得到的結(jié)論是：當(dāng) KV 數(shù)據(jù)量增加時，其 RT 會隨之線性增加，其 QPS 吞吐則會指數(shù)級下降。這一步測試結(jié)果帶來的啟示之一即是：通過分析 etcd 中的數(shù)據(jù)組成、外部流量特征以及數(shù)據(jù)訪問特點，盡可能地降低單 etcd 節(jié)點的數(shù)據(jù)規(guī)模。

目前螞蟻的 etcd 運維平臺具有如下數(shù)據(jù)分析功能：

• longest?N?KV?--- 長度最長的?N?個?KV

• top?N?KV?---?段時間內(nèi)訪問次數(shù)最多的?N?個?KV

• top?N?namespace?--- KV?數(shù)目最多的?N?個?namespace?

• verb?+?resoure?---?外部訪問的動作和資源統(tǒng)計

• 連接數(shù)?---?每個?etcd?節(jié)點的長連接數(shù)目

• client?來源統(tǒng)計 --- 每個?etcd?節(jié)點的外部請求來源統(tǒng)計

• 冗余數(shù)據(jù)分析 --- etcd?集群中近期無外部訪問的?KV?分布

根據(jù)數(shù)據(jù)分析結(jié)果，可以進(jìn)行如下工作：

• 客戶限流

• 負(fù)載均衡

• 集群拆分

• 冗余數(shù)據(jù)刪除

• 業(yè)務(wù)流量精細(xì)分析

1.集群拆分

前文提到，etcd 集群性能提升的一個經(jīng)典手段就是把 event 數(shù)據(jù)獨立拆分到一個獨立的 etcd 集群，因為 event 數(shù)據(jù)是 k8s 集群一中量級比較大、流動性很強(qiáng)、訪問量非常高的數(shù)據(jù)，拆分之后可以降低 etcd 的數(shù)據(jù)規(guī)模并減輕 etcd 單節(jié)點的外部客戶端流量。

一些經(jīng)驗性的、常規(guī)性的 etcd 拆分手段有：

• pod/cm

• node/svc

• event,?lease

這些數(shù)據(jù)拆分后，大概率能顯著提升 k8s 集群的 RT 與 QPS，但是更進(jìn)一步的數(shù)據(jù)拆分工作還是有必要的。依據(jù)數(shù)據(jù)分析平臺提供的熱數(shù)據(jù)【top N KV】量級以及外部客戶訪問【verb + resource】情況，進(jìn)行精細(xì)分析后可以作為 etcd 集群拆分工作的依據(jù)。

2.客戶數(shù)據(jù)分析

針對客戶數(shù)據(jù)的分析分為 longest N KV 分析、top N namespace。

一個顯然成立的事實是：單次讀寫訪問的 KV 數(shù)據(jù)越長，則 etcd 響應(yīng)時間越長。通過獲取客戶寫入的 longest N KV 數(shù)據(jù)后，可以與平臺使用方研究其對平臺的使用方法是否合理，降低業(yè)務(wù)對 k8s 平臺的訪問流量壓力和 etcd 自身的存儲壓力。

一般地，k8s 平臺每個 namespace 都是分配給一個業(yè)務(wù)單獨使用。前面提到 k8s 可能因為 list-all 壓力導(dǎo)致被壓垮，這些數(shù)據(jù)訪問大部分情況下都是 namespace 級別的 list-all。從平臺獲取 top N namespace 后，重點監(jiān)控這些數(shù)據(jù)量級比較大的業(yè)務(wù)的 list-all 長連接請求，在 kube-apiserver 層面對其采取限流措施，就可以基本上保證 k8s 集群不會被這些長連接請求打垮，保證集群的高可用。

3.冗余數(shù)據(jù)分析

etcd 中不僅有熱數(shù)據(jù)，還有冷數(shù)據(jù)。這些冷數(shù)據(jù)雖然不會帶來外部流量訪問壓力，但是會導(dǎo)致 etcd 內(nèi)存索引鎖粒度的增大，進(jìn)而導(dǎo)致每次 etcd 訪問 RT 時延增加和整體 QPS 的下降。

近期通過分析某大規(guī)模【7k node 以上】 k8s 集群 etcd 中的冗余數(shù)據(jù)，發(fā)現(xiàn)某業(yè)務(wù)數(shù)據(jù)在 etcd 中存儲了大量數(shù)據(jù)，其數(shù)據(jù)量大卻一周內(nèi)沒有訪問過一次，與業(yè)務(wù)方詢問后獲悉：業(yè)務(wù)方把 k8s 集群的 etcd 當(dāng)做其 crd 數(shù)據(jù)的冷備使用。與業(yè)務(wù)方溝通后把數(shù)據(jù)從 etcd 中遷移掉后，內(nèi)存 key 數(shù)目立即下降 20%?左右，大部分 etcd KV RT P99 延時立即下降 50%?~ 60%?之多。

4.負(fù)載均衡

k8s 平臺運維人員一般都有這樣一條經(jīng)驗：etcd 集群如果發(fā)生了啟停，需要盡快對所有 k8s kube-apiserver 進(jìn)行一次重啟，以保證 kube-apiserver 與 etcd 之間連接數(shù)的均衡。其原因有二：

• kube-apiserver 在啟動時可以通過隨機(jī)方式保證其與 etcd 集群中某個節(jié)點建立連接，但 etcd 發(fā)生啟停后，kube-apiserver 與 etcd 之間的連接數(shù)并無規(guī)律，導(dǎo)致每個 etcd 節(jié)點承擔(dān)的客戶端壓力不均衡；

• kube-apiserver 與 etcd 連接數(shù)均衡時，其所有讀寫請求有 2/3 概率是經(jīng)過 follower 轉(zhuǎn)發(fā)到 leader，保證整體 etcd 集群負(fù)載的均衡，如果連接不均衡則集群性能無法評估。

通過 etcd 運維平臺提供的每個 etcd 的連接負(fù)載壓力，可以實時獲取集群連接的均衡性，進(jìn)而決定運維介入的時機(jī)，保證 etcd 集群整體的健康度。

其實最新的 etcd v3.5 版本已經(jīng)提供了 etcd 客戶端和 etcd 節(jié)點之間的自動負(fù)載均衡功能，但這個版本才發(fā)布沒多久，目前最新版本的 k8s 尚未支持這個版本，可以及時跟進(jìn) k8s 社區(qū)對這個版本的支持進(jìn)度以及時獲取這一技術(shù)紅利，減輕平臺運維壓力。?

未來之路

通過一年多的包括 kube-apiserver 和 etcd 在內(nèi)的 k8s 高可用建設(shè)，目前 k8s 集群已經(jīng)穩(wěn)定下來，一個顯著的特征是半年內(nèi) k8s 集群沒有發(fā)生過一次 P 級故障，但其高可用建設(shè)工作不可能停歇?---?作為全球 k8s 規(guī)模化建設(shè)領(lǐng)導(dǎo)力象限的螞蟻集團(tuán)正在挑戰(zhàn) node 量級更大規(guī)模的 k8s 集群，這一工作將推動 etcd 集群建設(shè)能力的進(jìn)一步提升。

前面提到的很多 etcd 能力提升工作都是圍繞其 scale up 能力提升展開的，這方面的能力還需要更深層次的加強(qiáng)：

• etcd?最新?feature?地及時跟進(jìn)，及時把社區(qū)技術(shù)進(jìn)步帶來的開源價值轉(zhuǎn)換為螞蟻?k8s?平臺上的客戶價值

• 及時跟進(jìn)阿里集團(tuán)在?etcd?compact?算法優(yōu)化、etcd?單節(jié)點多?multiboltdb?的架構(gòu)優(yōu)化以及 kube-apiserver?的服務(wù)端數(shù)據(jù)壓縮等?etcd?優(yōu)化工作【見參考文檔?1】，對兄弟團(tuán)隊的工作進(jìn)行借鑒和反饋，協(xié)同作戰(zhàn)共同提升

• 跟進(jìn)螞蟻自身?k8s?平臺上?etcd?的性能瓶頸，提出我們自己的解決方案，在提升我們平臺的技術(shù)價值的同時反哺開源

除了關(guān)注 etcd 單節(jié)點性能的提升，我們下一步的工作將圍繞分布式 etcd 集群這一 scale out 方向展開。前面提到的 etcd 集群拆分工作，其本質(zhì)就是通過分布式 etcd 集群的方式提升 etcd 集群整體的性能：該集群的數(shù)據(jù)劃分方式是依據(jù) k8s 業(yè)務(wù)層面的數(shù)據(jù)類型進(jìn)行的。

該工作可以進(jìn)一步拓展為：不區(qū)分 KV 的業(yè)務(wù)意義，從單純的 KV 層面對把數(shù)據(jù)根據(jù)某種路由方式把數(shù)據(jù)寫入后端多 etcd 子集群，實現(xiàn) etcd 集群整體的冷熱負(fù)載均衡。

分布式 etcd 集群的實現(xiàn)有兩種方式：proxyless 和 proxy based：proxy based etcd 分布式集群的請求鏈路是 client[kube-apiserver]?-> proxy -> etcd server，而謂的 proxyless 分布式 etcd 集群的請求鏈路是 client[kube-apiserver]?-> etcd server。

proxy based etcd 分布式集群的好處是可以直接基于 etcd 社區(qū)提供的 etcd proxy 進(jìn)行開發(fā)，后期亦可回饋社區(qū)，實現(xiàn)其開源價值、技術(shù)價值和客戶價值的統(tǒng)一。但經(jīng)過測試：按照測試發(fā)現(xiàn)，kube-apiserver 經(jīng)過 proxy 向 etcd 發(fā)起讀寫請求后 RT ?和 QPS 降低 20%?~ 25%。所以下一步的工作重點是開發(fā) proxyless etcd 集群。

目前的拆分后的 etcd 分布式集群本質(zhì)或者 67%?的概率是 proxy based 分布式集群：kube-apiserver 的請求大概有三分之二的概率是經(jīng)過 follower 轉(zhuǎn)發(fā)到 leader，此處的 follower 本質(zhì)就是一個 proxy。如果 kube-apiserver 所有請求都是與 leader 直連后被處理，理論上當(dāng)前的 k8s 集群的 RT 和 QPS 就有 67%?* 20%?≈ 13.4%?的性能收益。

proxyless etcd 分布式集群的缺點是如果把 proxy 的路由邏輯放入 kube-apiserver 中，會造成 kube-apiserver 版本升級成本增加，但相比于至少 20%?【將來通過 etcd 集群規(guī)模擴(kuò)充這個收益肯定會更大】的收益，這個僅僅影響了 kube-apiserver 單個組件的版本升級的成本是值得的。

除了 multiple etcd clusters 的思路外，數(shù)據(jù)中間件團(tuán)隊基于 OBKV 之上實現(xiàn)了 etcd ?V3 API ，算是另一種比較好的技術(shù)路線，頗類似于本文開頭黃東旭提到的在 tikv 之上 etcd ?V3 API 接口層，可以稱之為類 etcd 系統(tǒng)，目前相關(guān)工作也在推進(jìn)中。

總之，隨著我們 k8s 規(guī)模越來越大，螞蟻集團(tuán) etcd 整體工作的重要性就日益凸顯。?如果說前期 etcd 的高可用建設(shè)之路是在泥濘小道上蹣跚前行，那么以后的 etcd 高可用建設(shè)之路必是康莊大道?---?道路越走越寬廣！

參看文檔

參考文檔 1：

https://www.kubernetes.org.cn/9284.html

參考文檔 2：

https://tech.meituan.com/2020/08/13/openstack-to-kubernetes-in-meituan.html

作者簡介

于雨（github @AlexStocks），dubbogo 社區(qū)負(fù)責(zé)人，一個有十一年服務(wù)端基礎(chǔ)架構(gòu)和中間件研發(fā)一線工作經(jīng)驗的程序員。

陸續(xù)參與和改進(jìn)過 Redis/Pika/Pika-Port/etcd/Muduo/Dubbo/dubbo-go/Sentinel-go 等知名項目，目前在螞蟻集團(tuán)可信原生技術(shù)部大規(guī)模 k8s 集群調(diào)度團(tuán)隊從事容器編排工作，參與維護(hù)全球規(guī)模最大的 Kubernetes 生產(chǎn)集群之一，致力于打造規(guī)模化、金融級、可信的云原生基礎(chǔ)設(shè)施。

歡迎對 Serverless 自動伸縮技術(shù)、自適應(yīng)混合部署技術(shù)以及 Kata/Nanovisor 等安全容器技術(shù)感興趣的同行或者 2022 屆應(yīng)屆畢業(yè)生加入我們。

聯(lián)系郵箱 xiaoyun.maoxy@antgroup.com 或者 yuyu.zx@antgroup.com。

本周推薦

我們做出了一個分布式注冊中心

2021-07-27

還在為多集群管理煩惱嗎？OCM來啦！

2021-07-20

RFC8998+BabaSSL---讓國密駛向更遠(yuǎn)的星辰大海

2021-07-13

MOSN 子項目 Layotto：開啟服務(wù)網(wǎng)格+應(yīng)用運行時新篇章

2021-06-21

總結(jié)

以上是生活随笔為你收集整理的蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。