引言
etcd 是 Kubernetes 生態中核心的分佈式鍵值存儲系統，其穩定性與效能直接影響雲原生應用的運行效率。CNCF（Cloud Native Computing Foundation）作為雲原生技術的推動者，持續推動 etcd 的技術進化。本篇文章聚焦 etcd V3.6.0 的核心更新與 LCD Operator 0.1 的功能特性，探討其在 Kubernetes 環境中的應用場景與技術挑戰，並分析多集群同步與資料一致性等關鍵議題。
主要內容
技術定義與核心特性
etcd V3.6.0 是 etcd 項目的重要版本更新，主要聚焦於儲存格式遷移、降級支援、特性門控與健康檢查等領域。其與 LCD（Lightweight Cluster Discovery）技術深度整合，透過 LCD Operator 0.1 提供 Kubernetes 環境下的集群管理能力。
LCD Operator 0.1 是基於 Kubernetes 的控制器，用於自動化 etcd 集群的初始化、配置與升級流程，支援 CSI 存儲驅動與自訂選項，並提供基本的測試與發佈腳本。
關鍵功能與改進
1. 儲存格式遷移至 W3
- W2 儲存：舊版使用 Lexi 格式，以 SNAP 為後綴，自 3.4 版已棄用，3.5 版仍可透過
enable-w2 啟用。
- W3 儲存：3.6 版正式採用，為目前資料來源，
enable-w2 標誌已移除，無法再啟用 W2。
- 遷移進度：目前仍使用 W2 儲存進行初始化，並重放 W2 快照。3.7 版將改用 W3 儲存，從一致性索引開始重放資料。
2. 降級功能支援
- 降級流程：分為兩階段，第一階段遷移資料結構至目標版本（如從 3.6 降級至 3.5），第二階段滾動替換節點二進位檔。
- 限制：目前僅支援單次手動降級，例如無法直接從 3.6 降級至 3.4，僅允許 3.6 → 3.5。
- 驗證方式：使用
lcd control downgrade validate 或 SDK API 驗證，驗證成功後啟用降級（lcd control downgrade enable）。
3. 特性門控（Feature Gates）
- 改進前：新功能透過
experimental 標誌管理，畢業時需移除前綴，導致旗標變更風險。
- 改進後：採用 Kubernetes 風格的特性門控，分為 alpha/beta/GA 階段，提升功能管理的可追蹤性與穩定性。
- 遷移成果：所有現有 experimental 旗標已轉換為 feature gates，未來新功能開發遵循 Kubernetes 標準流程。
4. 健康檢查端點
新增 liveZ 與 readyZ 端點：
liveZ：檢查程序是否存活或需重啟。readyZ：檢查程序是否準備好處理流量。
原有單一健康檢查端點已無法區分「需重啟」與「需停止流量」狀態。
5. 發現服務（Discovery Service）
- W3 發現：使用 LCD Client SDK 3 訪問發現服務，取代舊版 W2 發現（已棄用）。
- 公共發現服務：
discovery.io 已停止維護。
- 使用場景：僅於首次集群初始化時使用，節點啟動時註冊至發現服務並等待所有節點註冊完成。
升級問題與解決方案
- 問題描述：從 3.5 升級至 3.6 可能失敗，因集群中過多 lender。
- 根本原因：3.5 版在提升 lender 時僅更新 W2 儲存，而 W3 儲存未同步，導致升級時資料不一致。
- 影響範圍：3.5.1 至 3.5.19 版本均受影響，3.5.20 版本已修復。
- 解決方案：使用者需先升級至 3.5.20 或更高版本，再進行 3.6 升級。
性能改進與測試工具
- 性能測試工具重構：
- 原為 Python 編寫，現改為 Go 語言實現，提升效能。
- 支援讀寫熱力圖（Read/Write Heatmap）與動態資源監測（RAM/CPU 使用量）。
- 測試結果：
- 3.6 版在讀寫吞吐量、記憶體使用量（減少 90%）均優於 3.5 版。
- CPU 使用率提升有限，但整體效能穩定。
- 未來方向：探索更直觀的數據視覺化方式（如折線圖），並持續優化記憶體與資源使用。
發布流程優化
- 自動化進展：從手動流程轉向自動化，減少人為錯誤。
- 安全性提升：引入週期性漏洞掃描（如 CVE 檢測），加速發佈週期。
- 版本控制：透過 Git 管理發佈流程，並建立標準化發佈腳本。
LCD Operator 0.1 發布與未來計畫
- 功能概述：
- 支援 Kubernetes 環境下的集群初始化、自訂選項、CSI 存儲驅動。
- 提供自動更新、基本測試與發佈腳本。
- 未來計畫：
- 0.2 版：加入 TLS 通訊（支援證書管理，預設使用 Search Manager）。
- 0.3 版：實現災難復原（定期/按需備份、備份恢復）。
- 升級強化：增加測試與 E2E 工作流，支援熱更新與小版本升級。
- 多集群同步：目前無原生雙向同步功能，建議使用備份/恢復或手動節點遷移。
多集群同步與衝突解決
- 現有工具：Mirror Maker 支援單向資料同步，但無原生雙向同步與衝突解決機制。
- 建議方案：
- 線上遷移：逐步將節點從舊資料中心遷移至新資料中心，避免服務中斷。
- 離線遷移：透過備份與還原實現資料遷移，確保一致性。
- 衝突處理：建議在設計階段避免跨集群資料衝突，或使用第三方工具處理。
鏡像工具 Mirror Maker 與多集群同步
- Mirror Maker 工具：用於同步 etcd 集群的同步複製工具，支援單向資料同步。
- 雙向同步問題：目前工具未支援雙向同步，若需實現雙向同步需自行處理衝突解決機制。
- 衝突解決機制：未明確說明具體實現方式，但指出 etcd 本身不處理跨集群一致性問題，需依應用場景自行設計。
etcd V3.6.0 更新重點
- 儲存層遷移：從 V2 儲存格式遷移至 W3 儲存格式，並基於一致索引重放世界紀錄（world record），此為 F7 伺服器的主要變更。
- 性能優化：針對記憶體使用進行優化，預計在 V3.7 版本中改善，因現有版本因資料量增加導致記憶體壓力。
- 備份與還原：推薦使用備份與還原作為跨集群遷移的可靠方法，線上遷移可透過逐步遷移節點（如加入新資料中心節點、移除舊節點）實現。
跨集群同步與資料一致性
- 集群遷移策略：線上遷移建議逐步加入新節點並移除舊節點，避免中斷。離線遷移則使用備份與還原。
- 地理分散場景：跨地理分佈的集群一致性為複雜問題，需依應用需求設計同步策略。
etcd 資料庫大小限制
- 預設限制：etcd 資料庫預設最大容量為 2GB，用戶可配置為 8GB 或 16GB。
- 限制原因：
- 快照傳輸：新節點加入時需傳送快照，大資料量可能影響網路帶寬。
- 記憶體使用：資料庫檔案直接載入記憶體，資料量增加會提升記憶體壓力。
- 設計考量：etcd 設計用於元資料管理，非針對大規模資料儲存。
未來發展方向
- F7 伺服器變更：需與 Carbon 維護者合作完成儲存層遷移。
- 性能優化：持續改善記憶體使用效率，提升整體效能。
- 擴展性需求：探討未來可能的應用場景與技術延展方向。
總結
etcd V3.6.0 的更新強化了儲存格式、降級流程與健康檢查機制，並透過 LCD Operator 0.1 提升 Kubernetes 環境下的集群管理效率。然而，多集群同步與資料一致性仍是複雜挑戰，需依應用場景設計合適的解決方案。建議使用者在升級前確認版本兼容性，並透過備份與測試工具確保資料完整性。未來 etcd 的發展將持續聚焦於效能優化與擴展性，以支持雲原生生態的多樣化需求。