etcd：當前狀態和未來路線圖

etcd 是一個分散式鍵值儲存，它提供了一種可靠的方式來管理分散式系統的協調狀態。etcd 於 2013 年 6 月由 CoreOS（2018 年成為 Red Hat 的一部分）首次釋出。自 2014 年被 Kubernetes 採用以來，etcd 已成為 Kubernetes 叢集管理軟體設計的基礎部分，etcd 社群也呈指數級增長。etcd 目前已被多家公司用於生產環境，包括大型雲提供商環境，如 AWS、Google Cloud Platform、Azure 以及其他本地 Kubernetes 實現。CNCF 目前擁有 32 個符合要求的 Kubernetes 平臺和發行版，所有這些都使用 etcd 作為資料儲存。

在這篇博文中，我們將回顧最新 etcd 版本中取得的一些里程碑，並介紹 etcd 的未來路線圖。請在郵件列表 etcd-dev@googlegroups.com 上分享您對重要功能的想法和反饋。

etcd，2013 年

2014 年 6 月，Kubernetes 釋出，etcd 作為所有主控狀態的後端儲存。Kubernetes v0.4 使用了當時處於 alpha 階段的 etcd v0.2 API。隨著 Kubernetes 在 2015 年達到 v1.0 里程碑，etcd 穩定了其 v2.0 API。Kubernetes 的廣泛採用導致 etcd 的可伸縮性要求急劇增加。為了處理大量工作負載和不斷增長的規模要求，etcd 於 2016 年 6 月釋出了 v3.0 API。Kubernetes v1.13 最終放棄了對 etcd v2.0 API 的支援，並採用了 etcd v3.0 API。下表直觀地展示了 etcd 和 Kubernetes 的釋出週期。

etcd v3.1，2017 年初

etcd v3.1 的功能在版本升級期間提供了更好的讀取效能和更高的可用性。鑑於 etcd 至今在生產中的高使用率，這些功能對使用者非常有用。它實現了 Raft 讀取索引，繞過了 Raft WAL 磁碟寫入，實現了線性化讀取。追隨者從領導者請求讀取索引。領導者的響應表明追隨者是否與領導者同步。當追隨者的日誌是最新的時，仲裁讀取在本地提供，而無需透過完整的 Raft 協議。因此，讀取請求不需要磁碟寫入。etcd v3.1 引入了自動領導者轉移。當 etcd 領導者接收到中斷訊號時，它會自動將其領導者身份轉移給一個追隨者。這在叢集新增或刪除成員時提供了更高的可用性。

etcd v3.2 (2017 年夏季)

etcd v3.2 專注於穩定性。其客戶端已隨 Kubernetes v1.10、v1.11 和 v1.12 釋出。etcd 團隊仍然透過回溯所有錯誤修復來積極維護該分支。此版本引入了 gRPC 代理以支援、監視並將所有監視事件廣播合併為一個 gRPC 流。這些事件廣播每秒可達一百萬次。

etcd v3.2 還引入了更改，例如 `snapshot-count` 預設值從 10,000 更改為 100,000。透過更高的快照計數，etcd 伺服器在壓縮舊條目之前，會在記憶體中保留 Raft 條目更長時間。etcd v3.2 的預設配置顯示更高的記憶體使用量，同時為緩慢的追隨者提供了更多趕上的時間。這是減少快照發送頻率和增加記憶體使用量之間的權衡。使用者可以使用較低的 `etcd --snapshot-count` 值來減少記憶體使用量，或者使用較高的 `snapshot-count` 值來提高慢速追隨者的可用性。

etcd v3.2.19 中回溯的另一個新功能是 `etcd --initial-election-tick-advance` 標誌。預設情況下，重新加入的追隨者會快進選舉計時器，以加快其初始叢集引導。例如，啟動的追隨者節點只等待 200 毫秒，而不是完整的選舉超時 1 秒，然後才開始選舉。理想情況下，在 200 毫秒內，它會收到領導者的心跳並立即作為追隨者加入叢集。然而，如果發生網路分割槽，心跳可能會丟失，從而觸發領導者選舉。來自分割槽節點的投票請求具有很大的破壞性。如果它包含較高的 Raft 任期，當前領導者將被迫下臺。將 “initial-election-tick-advance” 設定為 false，重新加入的節點在擾亂叢集之前有更多機會接收領導者心跳。

etcd v3.3 (2018 年初)

etcd v3.3 繼續秉承穩定性的主題。其客戶端包含在 Kubernetes v1.13 中。以前，etcd 客戶端在網路斷開時會不加思索地重試，沒有任何退避或故障轉移邏輯。客戶端經常卡在分割槽節點上，影響了多個生產使用者。v3.3 客戶端負載均衡器現在使用 gRPC 健康檢查協議維護一個不健康端點列表，在瞬時斷開連線和網路分割槽時進行更高效的重試和故障轉移。此功能已回溯到 etcd v3.2，也包含在 Kubernetes v1.10 API 伺服器中。etcd v3.3 還提供了更可預測的資料庫大小。etcd 過去維護一個單獨的空閒列表資料庫來跟蹤不再使用並在事務後釋放的頁面，以便後續事務可以重用它們。然而，事實證明，持久化空閒列表需要高磁碟空間，併為 Kubernetes 工作負載引入高延遲。特別是當頻繁快照和大量讀取事務時，etcd 資料庫大小迅速從 16 MB 增長到 4 GB。etcd v3.3 停用空閒列表同步，並在重啟時重建空閒列表。開銷非常小，大多數使用者幾乎無法察覺。有關此問題的更多資訊，請參閱“資料庫空間超出”問題。

etcd v3.4 及更高版本

etcd v3.4 專注於改善操作體驗。它增加了 Raft 預投票功能，以提高領導者選舉的穩健性。當一個節點被隔離（例如網路分割槽）時，該成員將開始選舉，請求帶有增加的 Raft 術語的投票。當領導者收到具有更高術語的投票請求時，它會退位為追隨者。透過預投票，Raft 執行一個額外的選舉階段，以檢查候選人是否能獲得足夠的票數來贏得選舉。隔離的追隨者的投票請求被拒絕，因為它不包含最新的日誌條目。

etcd v3.4 增加了Raft 學習者，它作為非投票成員加入叢集，仍然接收領導者的所有更新。新增學習者節點不會增加仲裁大小，因此在成員配置重組期間提高了叢集可用性。它只作為備用節點，直到被提升為投票成員。此外，為了處理意外的升級失敗，v3.4 引入了etcd 降級功能。

etcd v3 儲存使用多版本併發控制模型來保留鍵更新作為事件歷史記錄。Kubernetes 執行壓縮以丟棄不再需要的事件歷史記錄，並回收儲存空間。etcd v3.4 將改進此儲存壓縮操作，提高後端大型讀取事務的併發性，並最佳化 Kubernetes 用例的儲存提交間隔。

為了進一步改進 etcd 客戶端負載均衡器，v3.4 負載均衡器已重寫，以利用新引入的 gRPC 負載均衡 API。透過利用 gRPC，etcd 客戶端負載均衡器程式碼庫大大簡化，同時保留了與 v3.3 實現的功能奇偶校驗，並透過在健康端點之間進行輪詢請求來改進整體負載均衡。有關更多詳細資訊，請參閱客戶端架構。

此外，etcd 維護者將繼續改進 Kubernetes 測試框架：用於可伸縮性測試的 kubemark 整合，帶 etcd 的 Kubernetes API 伺服器一致性測試以提供釋出建議和版本偏差策略，為每個雲提供商指定一致性測試要求等。

etcd 加入 CNCF

etcd 現在在 etcd-io 有了一個新家，並作為孵化專案加入了 CNCF。

與 Kubernetes 的協同努力推動了 etcd 的發展。沒有社群的反饋和貢獻，etcd 就不可能達到其成熟度和可靠性。我們期待 etcd 作為一個開源專案繼續發展，並很高興與 Kubernetes 和更廣泛的 CNCF 社群合作。

最後，我們要感謝所有貢獻者，特別感謝 Xiang Li 在 etcd 和 Kubernetes 中的領導作用。

• ←上一篇
• 下一篇→