做者 | 陳星宇（宇慕） 來源 | 阿里巴巴雲原生公衆號docker
背景
Kubernetes 採用 etcd 存儲其內部核心元數據信息。通過這些年的發展，尤爲是伴隨着這兩年雲原生的快速發展，Kubernetes被人們普遍認同並大規模被使用。伴隨阿里內部容器平臺 ASI 及公有云 ACK 集羣數飛速增加，底層存儲 etcd 集羣得到井噴式地增加，etcd 集羣數從原來的十幾個發展到了目前達到幾千個，它們分佈在世界各地，爲上層 Kubernetes 集羣以及其餘產品服務，服務用戶超萬個。shell
這些年，阿里雲原生 etcd 服務發生了翻天覆地的變化，這篇文章主要分享一下 etcd 服務在面對業務量大規模增加下遇到的問題以及咱們是如何解決的，但願對讀者瞭解 etcd 的使用和管控運維提供經驗分享。安全
具體將分三個部分進行介紹：架構
- etcd 集羣成本優化，利用率提高
- etcd 管控運維效率提高
- etcd 內核架構升級
etcd 集羣運行成本優化、利用率提高
近些年，etcd 集羣數井噴式增加。它的運行形態經歷了從 1.0 到 2.0 到 3.0 的變化，具體以下圖：運維
1.0 物理機時代
在一開始，咱們管控的 etcd 集羣數比較少，咱們在宿主機上使用 docker 直接運行 etcd 容器。即圖中的 1.0 模式。性能
2.0 雲上時代
1.0 模式運行 etcd 很是簡單，但也存在使用物理機運行軟件低效等常見問題，隨着阿里巴巴全面上雲的步伐，etcd 也全面將運行環境切到了雲上 ecs，存儲也換成了雲盤 ssd 或 essd。大數據
全面上雲優點明顯，利用阿里雲底層 Iaas 的 ecs 彈性和存儲雲盤，etcd 集羣可快速完成垂直水平伸縮，故障遷移也比 1.0 時容易的多。以集羣升配操做爲例，整個升級時間從最初的半小時下降到如今的 10 分鐘，能夠兼顧業務使用峯值和平常普通壓力，穩定承載阿里內部雙十一業務高峯以及外部多個公有云客戶春節大促活動。優化
3.0 大規模雲上時代
隨着 etcd 集羣數大量增加，運行這些集羣須要的 ecs 與雲盤成本愈來愈高，etcd 已成爲容器服務花費資金最多的部分之一，etcd 運行的成本成爲咱們必須面對並解決優化的問題。阿里雲
2.0 模式下使用獨佔 ecs 和雲盤咱們發現 etcd 資源利用率比較低，存在較多的資源浪費，咱們將 2.0 模式進行了進一步升級：將集羣進行混部，降級運行成本。但混部以後咱們遇到計算資源爭搶和集羣穩定性等風險，時常發生 etcd 集羣切主，致使上層依賴 etcd 軟件功能異常，例如 Kubernetes controller 切主影響用戶服務。url
針對這些問題，咱們首先將不一樣的 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 人力就能夠管理近萬集羣，人效比顯著。下圖展現了他的控制界面。
下面咱們詳細介紹一下 alpha 的具體功能，首先咱們看一下下面這幅圖，它描繪了一個 etcd 集羣從建立-》運行-》故障-》再運行-》中止-》銷燬的典型生命週期大圖。
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。
KubeMeet 杭州站開放報名！
4 月 17 日，雲原生基金會 CNCF 和阿里巴巴聯合主辦的「KubeMeet 開發者沙龍·雲原生應用管理專場」來到杭州啦！這裏有 Kubernetes 生態開發者都在關注的開源項目，以及阿里巴巴、攜程、第四範式的一線雲原生落地實踐。點擊此處趕忙報名吧！