從零開始入門 K8s | 手把手帶你理解 etcd
作者 | 曾凡鬆（逐靈） 阿里雲容器平臺高階技術專家
本文整理自《CNCF x Alibaba 雲原生技術公開課》第 16 講。
導讀：etcd 是用於共享配置和服務發現的分散式、一致性的 KV 儲存系統。本文從 etcd 專案發展所經歷的幾個重要時刻開始，為大家介紹了 etcd 的總體架構及其設計中的基本原理。希望能夠幫助大家更好的理解和使用 etcd。
一、etcd 專案的發展歷程
etcd 誕生於 CoreOS 公司，它最初是用於解決叢集管理系統中 OS 升級的分散式併發控制以及配置檔案的儲存與分發等問題。基於此，etcd 被設計為提供高可用、強一致的小型 keyvalue 資料儲存服務。
專案當前隸屬於 CNCF 基金會，被 AWS、Google、Microsoft、Alibaba 等大型網際網路公司廣泛使用。
最初，在 2013 年 6 月份由 CoreOS 公司向 GitHub 中提交了第一個版本的初始程式碼。
到了 2014 年的 6 月，社群發生了一件事情，Kubernetes v0.4 版本釋出。這裡有必要介紹一下 Kubernetes 專案，它首先是一個容器管理平臺，由谷歌開發並貢獻給社群，因為它集齊了谷歌在容器排程以及叢集管理等領域的多年經驗，從誕生之初就備受矚目。在 Kubernetes v0.4 版本中，它使用了 etcd 0.2 版本作為實驗核心元資料的儲存服務，自此 etcd 社群得到了飛速的發展。
很快，在 2015 年 2 月份，etcd 釋出了第一個正式的穩定版本 2.0。在 2.0 版本中，etcd 重新設計了 Raft 一致性演算法，併為使用者提供了一個簡單的樹形資料檢視，在 2.0 版本中 etcd 支援每秒超過 1000 次的寫入效能，滿足了當時絕大多數的應用場景需求。2.0 版本釋出之後，經過不斷的迭代與改進，其原有的資料儲存方案逐漸成為了新時期的效能瓶頸，之後 etcd 啟動了 v3 版本的方案設計。
2017 年 1 月份的時候，etcd 釋出了 3.1 版本，v3 版本方案基本上標誌著 etcd 技術上全面成熟。在 v3 版本中 etcd 提供了一套全新的 API，重新實現了更高效的一致性讀取方法，並且提供了一個 gRPC 的 proxy 用於擴充套件 etcd 的讀取效能。同時，在 v3 版本的方案中包含了大量的 GC 優化，在效能優化方面取得了長足的進步，在該版本中 etcd 可以支援每秒超過 10000 次的寫入。
2018 年，CNCF 基金會下的眾多專案都使用了 etcd 作為其核心的資料儲存。據不完全統計，使用 etcd 的專案超過了 30 個，在同年 11 月份，etcd 專案自身也成為了 CNCF 旗下的孵化專案。進入 CNCF 基金會後，etcd 擁有了超過 400 個貢獻組，其中包含了來自 AWS、Google、Alibaba 等 8 個公司的 9 個專案維護者。
2019 年，etcd 即將釋出全新的 3.4 版本，該版本由 Google、Alibaba 等公司聯合打造，將進一步改進 etcd 的效能及穩定性，以滿足在超大型公司使用中苛刻的場景要求。
二、架構及內部機制解析
總體架構
etcd 是一個分散式的、可靠的 key-value 儲存系統，它用於儲存分散式系統中的關鍵資料，這個定義非常重要。
一個 etcd 叢集，通常會由 3 個或者 5 個節點組成，多個節點之間通過 Raft 一致性演算法的完成分散式一致性協同，演算法會選舉出一個主節點作為 leader，由 leader 負責資料的同步與資料的分發。當 leader 出現故障後系統會自動地選取另一個節點成為 leader，並重新完成資料的同步。客戶端在多個節點中，僅需要選擇其中的任意一個就可以完成資料的讀寫，內部的狀態及資料協同由 etcd 自身完成。
在 etcd 整個架構中，有一個非常關鍵的概念叫做 quorum，quorum 的定義是 （n+1）/2，也就是說超過叢集中半數節點組成的一個團體，在 3 個節點的叢集中，etcd 可以容許 1 個節點故障，也就是隻要有任何 2 個節點可用，etcd 就可以繼續提供服務。同理，在 5 個節點的叢集中，只要有任何 3 個節點可用，etcd 就可以繼續提供服務，這也是 etcd 叢集高可用的關鍵。
在允許部分節點故障之後繼續提供服務，就需要解決一個非常複雜的問題：分散式一致性。在 etcd 中，該分散式一致性演算法由 Raft 一致性演算法完成，這個演算法本身是比較複雜的有機會再詳細展開，這裡僅做一個簡單的介紹以方便大家對其有一個基本的認知。Raft 一致性演算法能夠工作的一個關鍵點是：任意兩個 quorum 的成員之間一定會有一個交集（公共成員），也就是說只要有任意一個 quorum 存活，其中一定存在某一個節點（公共成員），它包含著叢集中所有的被確認提交的資料。正是基於這一原理，Raft 一致性演算法設計了一套資料同步機制，在 Leader 任期切換後能夠重新同步上一個 quorum 被提交的所有資料，從而保證整個叢集狀態向前推進的過程中保持資料的一致。
etcd 內部的機制比較複雜，但 etcd 給客戶提供的介面是簡單直接的。如上圖所示，我們可以通過 etcd 提供的客戶端去訪問叢集的資料，也可以直接通過 http 的方式（類似 curl 命令）直接訪問 etcd。在 etcd 內部，其資料表示也是比較簡單的，我們可以直接把 etcd 的資料儲存理解為一個有序的 map，它儲存著 key-value 資料。同時 etcd 為了方便客戶端去訂閱資料的變更，也支援了一個 watch 機制，通過 watch 實時地拿到 etcd 中資料的增量更新，從而實現與 etcd 中的資料同步等業務邏輯。
API 介紹
接下來我們看一下 etcd 提供的介面，這裡將 etcd 的介面分為了 5 組：
- 第一組是 Put 與 Delete。上圖可以看到 put 與 delete 的操作都非常簡單，只需要提供一個 key 和一個 value，就可以向叢集中寫入資料了，刪除資料的時候只需要指定 key 即可；
- 第二組是查詢操作。etcd 支援兩種型別的查詢：第一種是指定單個 key 的查詢，第二種是指定的一個 key 的範圍；
- 第三組是資料訂閱。etcd 提供了 Watch 機制，我們可以利用 watch 實時訂閱到 etcd 中增量的資料更新，watch 支援指定單個 key，也可以指定一個 key 的字首，在實際應用場景中的通常會採用第二種形勢；
- 第四組事務操作。etcd 提供了一個簡單的事務支援，使用者可以通過指定一組條件滿足時執行某些動作，當條件不成立的時候執行另一組操作，類似於程式碼中的 if else 語句，etcd 確保整個操作的原子性；
- 第五組是 Leases 介面。Leases 介面是分散式系統中常用的一種設計模式，其用法後面會具體展開。
資料版本機制
要正確使用 etcd 的 API，必須要知道內部對應資料版本號的基本原理。
首先 etcd 中有個 term 的概念，代表的是整個叢集 Leader 的任期。當叢集發生 Leader 切換，term 的值就會 +1。在節點故障，或者 Leader 節點網路出現問題，再或者是將整個叢集停止後再次拉起，都會發生 Leader 的切換。
第二個版本號叫做 revision，revision 代表的是全域性資料的版本。當資料發生變更，包括建立、修改、刪除，其 revision 對應的都會 +1。特別的，在叢集中跨 Leader 任期之間，revision 都會保持全域性單調遞增。正是 revision 的這一特性，使得叢集中任意一次的修改都對應著一個唯一的 revision，因此我們可以通過 revision 來支援資料的 MVCC，也可以支援資料的 Watch。
對於每一個 KeyValue 資料節點，etcd 中都記錄了三個版本：
- 第一個版本叫做 create_revision，是 KeyValue 在建立時對應的 revision；
- 第二個叫做 mod_revision，是其資料被操作的時候對應的 revision；
- 第三個 version 就是一個計數器，代表了 KeyValue 被修改了多少次。
這裡可以用圖的方式給大家展示一下：
在同一個 Leader 任期之內，我們發現所有的修改操作，其對應的 term 值始終都等於 2，而 revision 則保持單調遞增。當重啟叢集之後，我們會發現所有的修改操作對應的 term 值都變成了 3。在新的 Leader 任期內，所有的 term 值都等於3，且不會發生變化，而對應的 revision 值同樣保持單調遞增。從一個更大的維度去看，可以發現在 term=2 和 term=3 的兩個 Leader 任期之間，資料對應的 revision 值依舊保持了全域性單調遞增。
mvcc & streaming watch
瞭解 etcd 的版本號控制後，接下來如何使用 etcd 多版本號來實現併發控制以及資料訂閱（Watch）。
在 etcd 中支援對同一個 Key 發起多次資料修改，每次資料修改都對應一個版本號。etcd 在實現上記錄了每一次修改對應的資料，也就就意味著一個 key 在 etcd 中存在多個歷史版本。在查詢資料的時候如果不指定版本號，etcd 會返回 Key 對應的最新版本，當然 etcd 也支援指定一個版本號來查詢歷史資料。
因為 etcd 將每一次修改都記錄了下來，使用 watch 訂閱資料時，可以支援從任意歷史時刻（指定 revision）開始建立一個 watcher，在客戶端與 etcd 之間建立一個數據管道，etcd 會推送從指定 revision 開始的所有資料變更。etcd 提供的 watch 機制保證，該 Key 的資料後續的被修改之後，通過這個資料管道即時的推送給客戶端。
如下圖所示，etcd 中所有的資料都儲存在一個 b+tree 中（灰色），該 b+tree 儲存在磁碟中，並通過 mmap 的方式對映到記憶體用來支援快速的訪問。灰色的 b+tree 中維護著 revision 到 value 的對映關係，支援通過 revision 查詢對應的資料。因為 revision 是單調遞增的，當我們通過 watch 來訂閱指定 revision 之後的資料時，僅需要訂閱該 b+ tree 的資料變化即可。
在 etcd 內部還維護著另外一個 btree（藍色），它管理著 key 到 revision 的對映關係。當客戶端使用 key 查詢資料時，首先需要經過藍色的 btree 將 key 轉化為對應的 revision，再通過灰色的 btree 查詢到對應的資料。
細心的讀者會發現，etcd 將每一次修改都記錄下來會導致資料持續增長，這會帶來記憶體及磁碟的空間消耗，同時也會影響 b+tree 的查詢效率。為了解決這一問題，在 etcd 中會執行一個週期性的 Compaction 的機制來清理歷史資料，將一段時間之前的同一個 Key 的多個歷史版本資料清理掉。最終的結果是灰色的 b+tree 依舊保持單調遞增，但可能會出現一些空洞。
mini-transactions
在理解了 mvcc 機制及 watch 機制之後，繼續看 etcd 提供的 mini-transactions 機制。etcd 的 transaction 機制比較簡單，基本可以理解為一段 if-else 程式，在 if 中可以提供多個操作，如下圖所示：
If 裡面寫了兩個條件，當 Value(key1) 大於 "bar" 並且 Version(key1) 的版本等於 2 的時候，執行 Then 裡面指定的操作：修改 Key2 的資料為 valueX，同時刪除 Key3 的資料。如果不滿足條件，則執行另外一個操作：Key2 修改為 valueY。
在 etcd 內部會保證整個事務操作的原子性。也就是說 If 操作所有的比較條件，其看到的檢視一定是一致的。同時它能夠確保多個操作的原子性不會出現 Then 中的操作僅執行了一半的情況。
通過 etcd 提供的事務操作，我們可以在多個競爭中去保證資料讀寫的一致性，比如說前面已經提到過的 Kubernetes 專案，它正是利用了 etcd 的事務機制，來實現多個 KubernetesAPI server 對同樣一個數據修改的一致性。
lease 的概念及用法
lease 是分散式系統中一個常見的概念，用於代表一個分散式租約。典型情況下，在分散式系統中需要去檢測一個節點是否存活的時，就需要租約機制。
上圖示例中的程式碼示例首先建立了一個 10s 的租約，如果建立租約後不做任何的操作，那麼 10s 之後，這個租約就會自動過期。接著將 key1 和 key2 兩個 key value 繫結到這個租約之上，這樣當租約過期時 etcd 就會自動清理掉 key1 和 key2，使得節點 key1 和 key2 具備了超時自動刪除的能力。
如果希望這個租約永不過期，需要週期性的呼叫 KeeyAlive 方法重新整理租約。比如說需要檢測分散式系統中一個程序是否存活，可以在程序中去建立一個租約，並在該程序中週期性的呼叫 KeepAlive 的方法。如果一切正常，該節點的租約會一致保持，如果這個程序掛掉了，最終這個租約就會自動過期。
在 etcd 中，允許將多個 key 關聯在同一個 lease 之上，這個設計是非常巧妙的，可以大幅減少 lease 物件重新整理帶來的開銷。試想一下，如果有大量的 key 都需要支援類似的租約機制，每一個 key 都需要獨立的去重新整理租約，這會給 etcd 帶來非常大的壓力。通過多個 key 繫結在同一個 lease 的模式，我們可以將超時間相似的 key 聚合在一起，從而大幅減小租約重新整理的開銷，在不失靈活性同時能夠大幅提高 etcd 支援的使用規模。
三、典型的使用場景介紹
元資料儲存
Kubernetes 將自身所用的狀態儲存在 etcd 中，其狀態資料的高可用交給 etcd 來解決，Kubernetes 系統自身不需要再應對複雜的分散式系統狀態處理，自身的系統架構得到了大幅的簡化。
Server Discovery （Naming Service）
第二個場景是 Service Discovery，也叫做名字服務。在分散式系統中，通常會出現的一個模式就是需要多個後端（可能是成百上千個程序）來提供一組對等的服務，比如說檢索服務、推薦服務。
對於這樣一種後端服務，通常情況下為了簡化後端服務的運維成本（節點故障時隨時被替換），後端的這一程序會被類似 Kubernetes 這樣的叢集管理系統所排程，這樣當用戶（或上游服務）呼叫過來時，我們就需要一個服務發現機制來解決服務路由問題。這一服務發現問題可以利用 etcd 來高效解決，方式如下：
- 在程序內部啟動之後，可以將自身所在的地址註冊到 etcd；
- API 閘道器夠通過 etcd 及時感知到後端程序的地址，當後端程序發生故障遷移時會重新註冊到 etcd 中，API 閘道器也能夠及時地感知到新的地址；
- 利用 etcd 提供的 Lease 機制，如果提供服務的程序執行過程中出現了異常（crash），API 閘道器也可以摘除其流量避免呼叫超時。
在這一架構中，服務狀態資料被 etcd 接管，API 閘道器本身也是無狀態的，可以水平地擴充套件來服務更多的客戶。同時得益於 etcd 的良好效能，可以支援上萬個後端程序的節點，使得這一架構可以服務於大型的企業。
Distributed Coordination: leader election
在分散式系統中，有一種典型的設計模式就是 Master+Slave。通常情況下，Slave 提供了 CPU、記憶體、磁碟以及網路等各種資源 ，而 Master 用來調和這些節點以使其對外提供一個服務（比如分散式儲存，分散式計算）。典型的分散式儲存服務（HDFS）以及分散式計算服務（Hadoop）它們都是採用了類似這樣的設計模式。這樣的設計模式會有一個典型的問題：Master 節點的可用性。當 Master 故障以後，整個叢集的服務就掛掉了，沒有辦法再服務使用者的請求。
為了解決這個問題，典型的做法就是啟動多個 Master 節點。因為 Master 節點內會包含控制邏輯，多個節點之間的狀態同步是非常複雜的，這裡最典型的做法就是通過選主的方式，選出其中一個節點作為主節點來提供服務，另一個節點處於等待狀態。
通過 etcd 提供的機制可以很容易的實現分散式程序的選主功能，比如可以通過對同一個 key 的事務寫來實現搶主的邏輯。一般而言，被選主的 Leader 會將自己的 IP 註冊到 etcd 中，使得 Slave 節點能夠及時獲取到當前的 Leader 地址，從而使得系統按照之前單個 Master 節點的方式繼續工作。當 Leader 節點發生異常之後，通過 etcd 能夠選取出一個新的節點成為主節點，並且註冊新的 IP 之後，Slave 又能夠拉取新的主節點的 IP，繼續恢復服務。
Distributed Coordination 分散式系統併發控制
在分散式系統中，當我們去執行一些任務，比如說去升級 OS、或者說升級 OS 上的軟體的時候、又或者去執行一些計算任務的時候，出於對後端服務的瓶頸或者是業務穩定性的考慮，通常情況下需要控制任務的併發度。如果該任務缺少一個調和的 Master 節點，可以通過 etcd 來完成這樣的分散式系統工作。
在這個模式中通過 etcd 去實現一個分散式的訊號量，並且可以利用 etcd leases 機制來實現自動地剔除掉故障節點。在程序執行過程中，如果程序的執行週期比較長，我們可以將程序執行過程中的一些狀態資料儲存到 etcd，從而使得當程序故障之後且需要恢復到其他地方時，能夠從 etcd 中去恢復一些執行狀態，而不需要重新去完成整個的計算邏輯，以此來加速整個任務的執行效率。
本文總結
本文分享的主要內容就到此為止了，這裡為大家簡單總結一下：
- 第一部分，為大家介紹了 etcd 專案是如何誕生的，以及在 etcd 發展過程中經歷的幾個重要時刻；
- 第二部分，為大家介紹了 etcd 的架構以及其內部的基本操作介面，在理解 etcd 是如何實現高可用的基礎之上，展示了 etcd 資料的一些基本操作以及其內部的實現原理；
- 第三部分，介紹了三種典型的 etcd 使用場景，以及在對應的場景下，分散式系統的設計思路。
“阿里巴巴雲原生微信公眾號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。”