從零開始入門 K8s | etcd 性能優化實踐

作者 | 陳星宇（宇慕）  阿裡雲基礎技術中台技術專家

本文整理自

《CNCF x Alibaba 雲原生技術公開課》 第 17 講。

導讀：etcd 是容器雲平台用于存儲關鍵元資訊的元件。阿裡巴巴使用 etcd 已經有 3 年的曆史, 在今年 雙11 過程中它又一次承擔了關鍵角色，接受了 雙11 大壓力的檢驗。本文作者從 etcd 性能背景出發，帶領我們了解了 etcd server 端性能優化及 etcd client 使用最佳實踐，希望能夠為大家運作一個穩定而且高效的 etcd 叢集提供幫助。

一、etcd 簡要介紹

etcd 誕生于 CoreOs 公司，使用 Golang 語言開發，是一個分布式 KeyValue 存儲引擎。我們可以利用 etcd 來作為分布式系統中繼資料的存儲資料庫，存儲系統裡面重要的元資訊。etcd 同樣也被各大公司廣泛使用。

下圖為 etcd 的基本架構

如上所示，一個叢集有三個節點：一個 Leader 和兩個 Follower。每個節點通過 Raft 算法同步資料，并通過 boltdb 存儲資料。當一個節點挂掉之後，另外的節點會自動選舉出來一個 Leader，保持整個叢集的高可用特性。Client 可以通過連接配接任意一個節點完成請求。

二、了解 etcd 性能

首先我們來看一張圖：

上圖是一個标準的 etcd 叢集架構簡圖。可以将 etcd 叢集劃分成幾個核心的部分：例如藍色的 Raft 層、紅色的 Storage 層，Storage 層内部又分為 treeIndex 層和 boltdb 底層持久化存儲 key/value 層。它們的每一層都有可能造成 etcd 的性能損失。

首先來看 Raft 層，Raft 需要通過網絡同步資料，網絡 IO 節點之間的 RTT 和 / 帶寬會影響 etcd 的性能。除此之外，WAL 也受到磁盤 IO 寫入速度影響。

再來看 Storage 層，磁盤 IO fdatasync 延遲會影響 etcd 性能，索引層鎖的 block 也會影響 etcd 的性能。除此之外，boltdb Tx 的鎖以及 boltdb 本身的性能也将大大影響 etcd 的性能。

從其他方面來看，etcd 所在主控端的核心參數和 grpc api 層的延遲，也将影響 etcd 的性能。

三、etcd 性能優化 -server 端

下面具體來介紹一下 etcd server 端的性能優化。

etcd server 性能優化-硬體部署

server 端在硬體上需要足夠的 CPU 和 Memory 來保障 etcd 的運作。其次，作為一個非常依賴于磁盤 IO 的資料庫程式，etcd 需要 IO 延遲和吞吐量非常好的 ssd 硬碟，etcd 是一個分布式的 key/value 存儲系統，網絡條件對它也很重要。最後在部署上，需要盡量将它獨立的部署，以防止主控端的其他程式會對 etcd 的性能造成幹擾。

附：etcd 官方推薦的

配置要求資訊

。

etcd server 性能優化-軟體

etcd 軟體分成很多層，下面根據不同層次進行性能優化的簡單介紹。想深度了解的同學可以自行通路下面的 GitHub pr 來擷取具體的修改代碼。

• 首先是針對于 etcd 的 記憶體索引層 優化：優化内部鎖的使用減少等待時間。 原來的實作方式是周遊内部引 BTree 使用的内部鎖粒度比較粗，這個鎖很大程度上影響了 etcd 的性能，新的優化減少了這一部分的影響，降低了延遲。

具體可參照如下連結：

• 針對于 lease 規模 使用的優化：優化了 lease revoke 和過期失效的算法，将原來周遊失效 list 時間複雜度從 O(n) 降為 O(logn)，解決了 lease 規模化使用的問題。

• 最後是針對于 後端 boltdb 的使用優化：将後端的 batch size limit/interval 進行調整，這樣就能根據不同的硬體和工作負載進行動态配置，這些參數以前都是固定的保守值。

• 還有一點是由谷歌工程師優化的 完全并發讀特性 ：優化調用 boltdb tx 讀寫鎖使用，提升讀性能。

基于 segregated hashmap 的 etcd 内部存儲 freelist 配置設定回收新算法

其他的性能優化也非常多，這裡我們重點介紹一下由阿裡巴巴貢獻的一個

性能優化

。這個性能優化極大地提升了 etcd 内部存儲的性能，它的名字叫做：基于 segregated hashmap 的 etcd 内部存儲 freelist 配置設定回收新算法。

上圖是 etcd 的一個單節點架構，内部使用 boltdb 作為持久化存儲所有的 key/value，是以 boltdb 的性能好壞對于 etcd 的性能好壞起着非常重要的作用。在阿裡巴巴内部，我們大量使用 etcd 作為内部存儲中繼資料，在使用過程中我們發現了 boltdb 的性能問題，這裡分享給大家。

上圖中為 etcd 内部存儲配置設定回收的一個核心算法，這裡先給大家介紹一下背景知識。首先，etce 内部使用預設為 4KB 的頁面大小來存儲資料。如圖中數字表示頁面 ID，紅色的表示該頁面正在使用，白色的表示未使用。

當使用者想要删除資料的時候，etcd 并不會把這個存儲空間立即還給系統，而是内部先留存起來，維護一個頁面的池子，以提升下次使用的性能。這個頁面池子叫做 freelist，如圖所示，freelist 頁面 ID 為 43、45、 46、50、53 正在被使用，頁面 ID 為 42、44、47、48、49、51、52 處于空閑狀态。

當新的資料存儲需要一個連續頁面為 3 的配置時，舊的算法需要從 freelist 頭開始掃描，最後傳回頁面起始 ID 為 47，以此可以看到普通的 etcd 線性掃描内部 freelist 的算法，在資料量較大或者是内部碎片嚴重的情況下，性能就會急速的下降。

針對這一問題，我們設計并實作了一個基于 segregated hashmap 新的 freelist 配置設定回收算法。該算法将連續的頁面大小作為 hashmap 的 key，value 是起始 ID 的配置集合。當需要新的頁面存儲時，我們隻需要 O(1) 的時間複雜度來查詢這個 hashmap 值，快速得到頁面的起始 ID。

再去看上面例子，當需要 size 為 3 的連續頁面的時候，通過查詢這個 hashmap 很快就能找到起始頁面 ID 為 47。

同樣在釋放頁面時，我們也用了 hashmap 做優化。例如上圖當頁面 ID 為 45、46 釋放的時候，它可以通過向前向後做合并，形成一個大的連續頁面，也就是形成一個起始頁面 ID 為 44、大小為 6 的連續頁面。

綜上所述：新的算法将配置設定的時間複雜度從 O(n) 優化到了 O(1)，回收從 O(nlogn) 優化到了 O(1)，etcd 内部存儲不再限制其讀寫的性能，在真實的場景下，它的性能優化了幾十倍。從單叢集推薦存儲 2GB 可以擴大到 100GB。該優化目前在阿裡巴巴内部使用，并輸出到了開源社群。

這裡再提一點，本次說的多個軟體的優化，在新版本中的 etcd 中都會有釋出，大家可以關注使用一下。

四、etcd 性能優化 -client 端

再來介紹一下etce 用戶端的性能使用上的最佳實踐。

首先來回顧一下 etcd server 給用戶端提供的幾個 API：Put、Get、Watch、Transactions、Leases 等很多個操作。

針對于以上的用戶端操作，我們總結了幾個最佳實踐調用：

1. 針對于 Put 操作避免使用大 value，精簡精簡再精簡，例如 K8s 下的 crd 使用；
2. 其次，etcd 本身适用及存儲一些不頻繁變動的 key/value 中繼資料資訊。是以用戶端在使用上需要避免建立頻繁變化的 key/value。這一點例如 K8s下對于新的 node 節點的心跳資料上傳就遵循了這一實踐；
3. 最後，我們需要避免建立大量的 lease，盡量選擇複用。例如在 K8s下，event 資料管理：相同 TTL 失效時間的 event 同樣會選擇類似的 lease 進行複用，而不是建立新的 lease。

最後請大家記住一點：保持用戶端使用最佳實踐，将保證你的 etcd 叢集穩定高效運作。

本節總結

本節内容到這裡就結束了，這裡為大家總結一下：

• 首先我們了解了 etcd 性能背景，從背後原理了解潛在的性能瓶頸點；
• 解析 etcd server 端性能優化，從硬體/部署/内部核心軟體算法等方面優化；
• 了解 etcd client 使用最佳實踐；

最後希望各位同學讀完本文後，能夠有所收獲，為你們運作一個穩定而且高效的 etcd 叢集提供幫助。

“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”