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。透過利用 gPRC，etcd 用戶端負載平衡器程式碼庫已大幅簡化，同時保持與 v3.3 實作的功能對等性，並透過在健康端點之間輪詢請求來改進整體負載平衡。有關更多詳細資訊，請參閱用戶端架構。

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

etcd 加入 CNCF

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

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

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

• ←上一篇
下一篇→