![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/d177dddd51ab42f6ba352d1f18cb27a1.png)

作者 | 陳星宇（宇慕）
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/i-sqZ7HbogdxinxhZrt7tw)

# 背景
Kubernetes 採用 etcd 儲存其內部核心後設資料資訊。經過這些年的發展，尤其是伴隨著這兩年雲原生的快速發展，Kubernetes被人們廣泛認同並大規模被使用。伴隨阿里內部容器平臺 ASI 及公有云 ACK 叢集數飛速增長，底層儲存 etcd 叢集獲得井噴式地增長，etcd 叢集數從原來的十幾個發展到了目前達到幾千個，它們分佈在世界各地，為上層 Kubernetes 叢集以及其他產品服務，服務使用者超萬個。

這些年，阿里雲原生 etcd 服務發生了翻天覆地的變化，這篇文章主要分享一下 etcd 服務在面對業務量大規模增長下遇到的問題以及我們是如何解決的，希望對讀者瞭解 etcd 的使用和管控運維提供經驗分享。

具體將分三個部分進行介紹：

- etcd 叢集成本最佳化，利用率提升
- etcd 管控運維效率提升
- etcd 核心架構升級

# etcd 叢集執行成本最佳化、利用率提升
近些年，etcd 叢集數井噴式增長。它的執行形態經歷了從 1.0 到 2.0 到 3.0 的變化，具體如下圖：

![1.jpg](https://ucc.alicdn.com/pic/developer-ecology/5c5a32fc2e7e447180323edce1bf0394.jpg)

## 1.0 物理機時代
在一開始，我們管控的 etcd 叢集數比較少，我們在宿主機上使用 docker 直接執行 etcd 容器。即圖中的 1.0 模式。

## 2.0 雲上時代
1.0 模式執行 etcd 非常簡單，但也存在使用物理機執行軟體低效等常見問題，隨著阿里巴巴全面上雲的步伐，etcd 也全面將執行環境切到了雲上 ecs，儲存也換成了雲盤 ssd 或 essd。

全面上雲優勢明顯，利用阿里雲底層 Iaas 的 ecs 彈性和儲存雲盤，etcd 叢集可快速完成垂直水平伸縮，故障遷移也比 1.0 時容易的多。以叢集升配操作為例，整個升級時間從最初的半小時降低到現在的 10 分鐘，可以兼顧業務使用峰值和日常普通壓力，穩定承載阿里內部雙十一業務高峰以及外部多個公有云客戶春節大促活動。

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/8780c0c419214773a5f9e1fda80a2f15.jpg)

## 3.0 大規模雲上時代
隨著 etcd 叢集數大量增長，執行這些叢集需要的 ecs 與雲盤成本越來越高，etcd 已成為容器服務花費資金最多的部分之一，etcd 執行的成本成為我們必須面對並解決最佳化的問題。

2.0 模式下使用獨佔 ecs 和雲盤我們發現 etcd 資源利用率比較低，存在較多的資源浪費，我們將 2.0 模式進行了進一步升級：將叢集進行混部，降級執行成本。但混部之後我們遇到計算資源爭搶和叢集穩定性等風險，時常發生 etcd 叢集切主，導致上層依賴 etcd 軟體功能異常，例如 Kubernetes controller 切主影響使用者服務。

針對這些問題，我們首先將不同的 etcd 叢集根據不同的服務質量和 SLO 拆分成多種型別，類似 Kubernetes 中 Best effort、Burstable 和 Guaranteed 3 種型別，把不同型別的叢集放在不同的資源池中執行管理。混合部署由於採用了高度打散, 隨機的模式, 再加上我們的叢集使用者很多，對 etcd 的熱點請求被分割的很散，沒有聚集，穩定性問題例如叢集切主次數大量降低。在保證穩定性的前提下提升了資源利用率的目的，成本下降明顯。

# 管控運維效率提升
早期我們運維管理 etcd 叢集的方式比較簡單，採用 shell 指令碼基本可以涵蓋 etcd 叢集生命週期全過程，例如叢集建立、刪除，遷移都利用指令碼完成。以前的這種小作坊模式隨著叢集數的井噴式增長越來越不適用，我們遇到 etcd 叢集生產速度慢，適配底層 IaaS 變化難度大等問題，執行時叢集管理效率也很低。

針對這些運維管控效率低的問題，我們擁抱雲原生生態，用 Kubernetes 作為執行 etcd 的底座，並基於開源的 etcd-operator，經過幾年的研發，適配阿里雲底層 IaaS，修改了很多開源的 bug, 將 etcd 管控運維動作標準化，功能覆蓋 etcd 管控全生命週期，推出了新的 etcd 運維管控後臺 alpha, 我們利用 alpha 統一了阿里巴巴內部的 etcd 叢集及公有云 ACK 上的 etcd 叢集管控，極大地提高了我們管控運維 etcd 叢集的效率。目前我們投入 0.5 人力就可以管理近萬叢集，人效比顯著。下圖展示了他的控制介面。

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/99293f0149b94ab09cd05c53a65cfc5c.jpg)

下面我們詳細介紹一下 alpha 的具體功能，首先我們看一下下面這幅圖，它描繪了一個 etcd 叢集從建立-》執行-》故障-》再執行-》停止-》銷燬的典型生命週期大圖。

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/5631f9740caf4a359110d355ada2fdb1.jpg)

alpha 做的事情就是覆蓋圖上的方方面面，具體分為以下兩部分：

## 1. etcd 叢集生命週期管理

- etcd 叢集建立，銷燬，停止，升級，故障恢復等。
- etcd 叢集狀態監控，包括叢集健康狀態、member 健康狀態，訪問量，儲存資料量等。
- etcd 異常診斷、預案、黑盒探測，配置巡檢等。

## 2. etcd 資料管理

etcd 資料管理包括資料遷移、備份管理以及恢復，髒資料清理，熱點資料識別等。這塊是 alpha 的特色，我們發現開源或其他產品這方面做得工作很少。我們做的功能具體如下。

### **1）etcd 資料備份及恢復**

兩種方式如下：

- 傳統模式冷備：支援從 etcdserver 將 snapshot 資料備份至阿里雲 OSS 或本地，故障時可以根據這個 snapshot 備份檔案恢復。

- raft learner 熱備：對於新版本的使用了 raft learner 特性的 etcd 叢集，我們可以使用 learner 作為熱備節點，當故障發生時，我們強制將 learner 轉換為正常節點，並將客戶端訪問切到這個新節點上，相比於傳統方式故障恢復時間更快，並且 learner 可以部署在不同的地域，實現異地多活的能力。
### **2）髒資料清理**
我們可以根據指定 etcd key 字首刪除垃圾 kv 的能力，降低 etcd server 儲存壓力。

### **3）熱點資料識別**
我們開發了按照 etcd key 字首進行聚合分析熱點 key 的能力，另外還可以分析不同 key 字首的 db 儲存使用量。利用這個能力，我們多次幫助客戶排查分析 etcd 熱點 key，解決 etcd 濫用問題，這個在大規模 etcd 叢集上是一個必備的能力。

### **4）資料遷移能力，兩種方式**

- snapshot 方式：透過 etcdsnapshot 備份，再恢復進行遷移方式。
- raft learner 模式：我們使用 raft learner 特性可以快速從原叢集分裂衍生出新的叢集實現叢集遷移。

### **5）資料水平拆分**
當叢集資料儲存資料量超大時，我們支援使用水平拆分將不同客戶資料拆分儲存到不同的 etcd 叢集中。我們在阿里內部 ASI 叢集就用了這個功能，使其支援超萬規模節點。

總結一下，我們採用 Kubernetes 作為 etcd 叢集的執行底座，基於開源 operator 改良適配研發了新的 etcd 管控軟體 alpha，覆蓋 etcd 全生命週期管控工作，一套軟體管理所有 etcd 叢集，顯著提升了 etcd 管控效率。

# etcd 核心架構升級更新
etcd 是雲原生社群中非常重要的一款軟體，幾年的演進發展，解決了很多 bug, 提升了核心的效能和儲存容量。但開源軟體就像是一個毛坯房，真正在生產環境使用問題還是有的，阿里內部有更大資料儲存規模和效能方面的要求，另外 etcd 自身多租戶共享使用 QoS 控制能力很弱，不適用於我們的使用場景。

我們早期使用開源的 etcd 3.2/3.3 版本, 針對一些我們的使用場景需求，後續我們加入了一些穩定性和安全增強，形成了現在我們使用阿里內部版本，如下展示了重要的幾個不同：

## 1. 自適應歷史資料清理 compact 技術

etcd 會儲存使用者資料的歷史值，但是它不能長久的儲存所有歷史值，否則儲存空間會不足。因此 etcd 內部會利用 Compact 機制週期性地清理歷史值資料。當我們的叢集超大，資料量超大時，每次清理對執行時效能影響很大，可以類比一次 full gc。本技術可以根據業務請求量調整 Compact 時機，避開業務使用高峰期, 減少干擾。

## 2. 基於 raft learner 的只讀節點水平擴充套件能力

raft learner 是 raft 協議中的一種特殊的角色，他不參與 leader 選舉， 但是可以從 leader 處獲得叢集中最新的資料，因此他可以作為叢集的只讀節點進行水平擴充套件，提升叢集處理讀請求的能力。

## 3. 基於 raft learner 的熱備節點

除了上面說的 raft learner 可以作為只讀節點，我們也可以將其使能用於作為叢集的熱備節點，目前我們廣泛使用熱備節點做異地雙活，保證叢集高可用。

## 4. etcd 叢集 QoS 能力

公有云上，我們有大量的使用者採用共享 etcd 叢集的方式使用 etcd, 在這種多租戶使用場景下我們即需要保證租戶公平使用 etcd 儲存資源，也要保證穩定性即不會因為某一租戶的濫用將叢集整體搞掛，影響其他租戶使用。為此我們自研了相應的QoS限流功能，可以實現不同租戶執行時讀寫資料流量限制以及靜態儲存資料空間限制。

# 總結
阿里雲採用 etcd 服務化做容器服務的核心資料儲存系統已經有了將近 4 年的歷史，我們積累了大量的運維管控 etcd 的經驗和使用 etcd 的最佳實踐，這篇文章分享了我們在降本提效，核心最佳化方面的一些實踐。

近年來隨著雲原生的浪潮，etcd 也獲得前所未有地急速發展，etcd 去年已從 cncf 正式畢業。阿里云為 etcd 社群貢獻了重要的 feature 和 bug fix，積極參與社群，汲取社群營養，反哺貢獻社群，可以預見未來 etcd 叢集還會繼續保持高速的增長，我們將繼續在降本增效，保證穩定性和可靠性上持續投入努力。我們非常歡迎有興趣的同學加入我們，聯絡 xingyu.chenxingyu@alibaba-inc.com。

阿里巴巴雲原生 etcd 服務叢集管控最佳化實踐

相關文章