作者：尹珉，KubeSphere Ambassador & Contributor，KubeSphere 社區用戶委員會杭州站站長。
1. 開篇：揭開神祕面紗，etcd 如何驅動 KubeSphere 高效運轉
在雲原生時代，etcd 作爲 Kubernetes 生態中不可或缺的核心組件，扮演着 KubeSphere 集羣“神經系統”的角色。它利用 Raft 一致性算法提供強大的分佈式鍵值存儲能力，確保集羣狀態信息的實時同步和持久化。
每當在 KubeSphere 中執行資源操作時，這些指令首先通過 etcd 進行處理和分發，從而實現對整個集羣狀態的瞬時更新與管理。正是由於 etcd 的存在，KubeSphere 才得以在大規模容器編排中展現卓越的性能和穩定性。
接下來，我們將深入探索 etcd 如何巧妙地融入 KubeSphere 生態系統，並通過實際應用場景展示其對提升平臺工作效率和可靠性的關鍵作用。
2. 時光機：從誕生到崛起，etcd 如何在雲原生時代嶄露頭角
etcd 的旅程始於 2013 年 CoreOS 團隊的一項創新嘗試，隨着其 V1 和 V2 版本的發展，逐漸奠定了在分佈式系統數據一致性解決方案中的地位。從 etcd V1、V2 到 V3 版本的迭代過程中，性能不斷提升，穩定性日益增強，功能上也不斷豐富和完善。
經歷數次重要升級後，etcd V3 版本尤其顯著地解決了 Kubernetes 發展過程中面臨的存儲瓶頸問題。在性能方面，通過優化實現了更快的數據讀寫速度；在穩定性上，引入了更爲健壯的一致性保證機制；在功能上，則擴展了 API 接口，增強了安全性與可管理性。
因此，etcd 憑藉這些改進，在性能、穩定性和功能上的卓越表現成功捍衛了作爲 Kubernetes 核心存儲組件的地位，並在雲原生時代中扮演着不可或缺的角色，持續推動整個生態系統的進步與發展。
3. 深度剖析：etcd 核心原理與架構設計，它是如何做到數據存儲的萬無一失
3.1 基礎架構圖
etcd 是典型的讀多寫少存儲，實際業務場景中，讀一般佔據 2/3 以上的請求。爲了讓大家對 etcd 每個模塊有一定的初步瞭解，簡單介紹一下每個模塊的功能作用。
-
Client 層：etcd 提供了 v2 和 v3 兩個版本的 API 客戶端庫，通過負載均衡、節點故障自動轉移等機制簡化了業務集成過程，有效提升了開發效率與服務穩定性。
-
API 網絡層：該層處理客戶端與服務器以及服務器間的通信。v2 API 基於 HTTP/1.x 協議，而 v3 API 則使用 gRPC 協議，並通過 grpc-gateway 支持 HTTP/1.x 調用以滿足多語言需求。此外，Raft 一致性算法驅動下的服務器間通信也採用 HTTP 協議來實現數據複製和 Leader 選舉等功能。
-
Raft 算法層：這一關鍵層實現了諸如 Leader 選舉、日誌複製及 ReadIndex 等核心特性，確保了 etcd 集羣中多個節點間的數據一致性和高可用性。
-
功能邏輯層：在此層面上，etcd 的核心模塊包括 KV 存儲、多版本併發控制（MVCC）、權限驗證（Auth）、租約管理（Lease）以及數據壓縮（Compactor）等組件，其中 MVCC 模塊由 treeIndex 和 boltdb 組成，用於高效且安全地處理鍵值操作。
-
存儲層：爲保證數據安全性與持久化，存儲層包含預寫日誌（WAL）和快照（Snapshot）機制，以及用於存儲元數據和用戶數據的 boltdb 數據庫。WAL 防止 etcd 在崩潰後丟失數據，而 boltdb 則負責實際的數據存儲與檢索。
3.2 etcd 實現高可用、數據一致性的祕訣
祕訣就是 Raft 算法，旨在簡化分佈式系統中的共識問題理解與實現。它將複雜的共識過程分解爲三個關鍵環節：
-
Leader 選舉：確保在 Leader 節點失效時能快速重新選舉出新的 Leader。
-
日誌複製：通過僅允許 Leader 節點寫入日誌，並負責向 Follower 節點複製日誌記錄，以保證集羣內部數據一致性。
-
安全性：在安全性方面，Raft 算法設計了嚴格的規則，例如一個任期內僅產生一個有效的 Leader、先前已提交的日誌條目在新 Leader 上必定存在，且所有節點的狀態機應用的相同位置應具有相同的日誌內容。這一系列機制共同保障了分佈式系統的穩定性和一致性。
3.3 探祕 etcd 讀請求：一次閃電般的數據檢索之旅
在分佈式系統背景下，看似簡單的數據讀取操作實則蘊含複雜機制。對於 etcd 這類追求高可用與強一致性的鍵值存儲系統，每一次讀請求均是對底層技術細節和算法智慧的深度實踐。面對大規模集羣環境，當客戶端發送讀取指令時，etcd 如何確保快速準確地響應呢？接下來，我們一起揭示 etcd 讀請求背後的核心技術流程。
-
客戶端發起請求：應用通過 etcd 的 v2 或 v3 版本 API 客戶端庫發送讀取鍵值對的請求，支持 HTTP/1.x 和 gRPC 協議。
-
Raft 算法交互：對於讀操作，etcd 採用 ReadIndex 機制。客戶端將讀請求發送至當前 Leader 節點，Leader 節點先記錄下這次讀請求，然後在提交一個新的日誌條目後，再響應客戶端的讀請求，確保在此期間沒有新的寫入導致集羣狀態改變。
-
一致性保證：Leader 節點根據 Raft 算法確保所有已提交的日誌條目已被集羣內所有 Follower 節點複製，並達到一致狀態。
-
KV 存儲查詢：Leader 節點從內部 MVCC（多版本併發控制）模塊中的 boltdb 數據庫中檢索對應鍵的最新有效版本數據。
-
返回結果：一旦獲取到數據，Leader 節點將結果返回給客戶端，完成讀取操作。
在深入探討 etcd 的讀流程時，我們觸及到了其核心機制——線性讀與串行讀。這兩種讀模式分別應對不同的一致性需求場景。接下來，我們只對它們的含義做一個簡單的解釋：
-
串行讀（Serializable Read）適用於對數據實時性要求不嚴苛的情況，直接從節點狀態機中獲取數據，實現低延遲、高吞吐，但可能存在一定的數據一致性風險。
-
線性讀（Linearizable Read）則是爲了滿足關鍵業務操作對強一致性的需求，確保任何更新後的值都能被後續請求及時準確地訪問到，即使集羣中有多個節點，客戶端通過線性讀也能如同訪問單一節點般獲得最新且已達成共識的數據。儘管相比串行讀可能帶來更高的延時和較低的吞吐，但在要求嚴格數據一致性的場景下，線性讀是 etcd 默認且理想的讀取方式。
4. 實戰演練：構建 KubeSphere 環境下的 etcd 服務
4.1 什麼是 KubeSphere？
KubeSphere 是在 Kubernetes 之上構建的面向雲原生應用的分佈式操作系統，完全開源，支持多雲與多集羣管理，提供全棧的 IT 自動化運維能力，簡化企業的 DevOps 工作流。它的架構可以非常方便地使第三方應用與雲原生生態組件進行即插即用 (plug-and-play) 的集成。
4.2 架構說明
KubeSphere 將前端與後端分開，實現了面向雲原生的設計，後端的各個功能組件可通過 REST API 對接外部系統。可參考 API 文檔。下圖是系統架構圖。KubeSphere 無底層的基礎設施依賴，可以運行在任何 Kubernetes、私有云、公有云、VM 或物理環境（BM）之上。此外，它可以部署在任何 Kubernetes 發行版上。
4.3 爲什麼選擇 KubeKey
KubeKey 由 Go 語言開發，使用便捷、輕量，支持多種主流 Linux 發行版。KubeKey 支持多種集羣部署模式，例如 All-in-One、多節點、高可用以及離線集羣部署。KubeKey 也支持快速構建離線安裝包，加速離線交付場景下的集羣交付效率。KubeKey 實現多節點並行安裝，且利用 Kubeadm 對集羣和節點進行初始化，極大地節省了集羣部署時間，同時也遵循了 Kubernetes 社區主流集羣部署方法。KubeKey 提供內置高可用模式，支持一鍵部署高可用 Kubernetes 集羣。
4.4 環境準備
爲了演示效果使用 all-in-one 快速部署。
4.4.1 獲取 KubeKey
export KKZONE=cn
curl -sfL https://get-kk.kubesphere.io | VERSION=v3.0.13 sh -
chmod +x kk
4.4.2 安裝 Kubernetes+KubeSphere
./kk create cluster --with-kubernetes v1.22.12 --with-kubesphere v3.4.1
4.4.3 檢查集羣狀態
4.4.4 安裝 etcdctl 工具（可選）
使用 KubeKey 部署集羣會默認安裝 etcdctl。
https://github.com/etcd-io/etcd/releases #自行下載
tar -zxvf etcd-v3.5.11-linux-amd64.tar.gz
cp etcdctl /usr/local/bin/
4.4.5 獲取證書並查看 etcd 狀態
說明：KubeKey 安裝集羣時默認 etcd 使用二進制安裝，證書路徑默認在此處。
/etc/ssl/etcd/ssl
通過採用 KubeKey 工具實施最小化部署案例，展示瞭如何運用安全證書機制來實現對 etcd 的訪問以監控集 etcd 服務狀態。儘管此處演示以單一實例呈現，但在實際生產環境中，etcd 服務必然是基於高可用集羣模式運行，始終堅守着高可靠性的核心原則。
4.6 etcd 部署建議
4.6.1 系統要求
爲保證 etcd 性能，推薦使用 SSD 硬盤，並通過工具（如 fio）進行磁盤速度評估。建議系統配置至少與默認存儲配額（2GB）相等的 RAM，一般推薦 8GB 以上以避免性能下降。典型部署中，etcd 集羣應在具有雙核 CPU、2GB 內存和 80GB SSD 的專用服務器上運行。請根據實際工作負載對硬件配置進行調整並預先測試，確保生產環境性能達標。
4.6.2 集羣成員數量儘量爲奇數
etcd 集羣達成狀態更新共識需要多數節點參與，即至少（n/2）+1 個成員在具有 n 個節點的集羣中。對於奇數節點數量的集羣，增加一個節點雖表面上增強了系統規模，但實際上降低了容錯性：相同數量節點故障時仍能保持仲裁，但更多節點故障可能導致仲裁丟失。因此，在集羣無法容忍額外故障且新節點可能註冊失敗的情況下，貿然添加節點是危險的，因爲這可能導致永久性的仲裁損失。
4.6.3 最大集羣大小不超過 7 個
理論上，etcd 集羣規模無明確上限，但實踐中推薦不超過 7 個節點。參照 Google 內部廣泛部署的 Chubby 鎖服務經驗，建議維持 5 節點配置。這樣的集羣能容忍兩個成員故障，通常已滿足需求。儘管更大集羣提升容錯性，但會因數據在更多節點上的複製而導致寫入性能下降。
5. etcd 集羣運維那些事兒
5.1 監控及告警
在構建和運維 etcd 集羣時，監控是確保業務穩定性和提前識別風險的關鍵步驟。
etcd 提供了衆多 metrics，按模塊劃分包括磁盤、網絡、MVCC 事務、gRPC RPC 和 etcdserver 等核心指標，用於展示集羣健康狀況。爲了有效監控這些指標，推薦使用 Prometheus 服務採集 etcd 2379 端口的 metrics 數據，並可通過靜態或動態配置實現。
5.1.1 靜態配置
靜態配置需手動在 Prometheus 配置文件中的 scrape_configs 下添加新 job，內容包含被監控的 etcd 集羣地址，如開啓了認證還需配置證書等。
示例：
scrape_configs:
- job_name: 'etcd'
static_configs:
- targets: ['<etcd-node-1>:2379', '<etcd-node-2>:2379', '<etcd-node-3>:2379']
metrics_path: '/metrics'
scheme: 'https'
tls_config:
ca_file: /path/to/prometheus-server/ca.pem # 在Prometheus服務器上的CA證書路徑
cert_file: /path/to/prometheus-server/client.pem # 客戶端證書路徑
key_file: /path/to/prometheus-server/client-key.pem # 客戶端密鑰路徑
5.1.2 動態配置
動態配置藉助 Prometheus-Operator 的 ServiceMonitor 機制，可自動發現並採集 Kubernetes 集羣中的 etcd 服務 metrics。通過創建 ServiceMonitor 資源，Prometheus 可根據 Namespace 和 Labels 自動關聯待監控的服務 Endpoint。
示例：
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: etcd-service-monitor
namespace: monitoring
spec:
selector:
matchLabels:
app: etcd # 根據服務標籤選擇匹配的服務
endpoints:
- port: http-metrics
scheme: https
tlsConfig:
caFile: /etc/prometheus/secrets/etcd-certs/ca.crt
certFile: /etc/prometheus/secrets/etcd-certs/client.crt
keyFile: /etc/prometheus/secrets/etcd-certs/client.key
insecureSkipVerify: true
namespaceSelector:
matchNames:
- kube-system # 指定監控哪個命名空間下的服務
獲取監控數據後，利用 Prometheus 與 Alertmanager 組件設置告警規則至關重要，重點關注影響集羣可用性的核心 metric，例如 Leader 狀態、切換次數及 WAL 和事務操作延時等。社區提供了一些參考告警規則。
最後，爲了提升運維效率和問題定位能力，可以基於收集到的 metrics，在 Grafana 中創建可視化面板，展示集羣 Leader 狀態、key 總數、watcher 數、出流量以及 WAL 持久化延時等關鍵運行狀態指標。
5.2 數據及還原
在完成監控與告警設置後，確保 etcd 集羣在生產環境安全使用還需進行數據備份。針對數據備份，有以下幾種方法：
5.2.1 手動備份恢復
通過指定端口、證書進行手動備份。
etcdCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
snapshot save <backup-file-location>
使用備份的數據進行恢復。
etcdCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
restore save <backup-file-location>
5.2.2 定時自動備份
建議每小時至少備份一次，可通過定時任務實現。
5.2.3 自動化備份
利用 etcd-backup-operator 工具，通過創建備份任務 CRD 實現自動化備份管理，例如配置備份頻率、最大保留備份數量以及 S3 存儲等參數。
示例：
apiVersion: "etcd.database.coreos.com/v1beta2"
kind: etcdBackup
metadata:
name: example-etcd-cluster-backup
spec:
etcdEndpoints: ["http://etcd-cluster-endpoint:2379"] # 替換爲你的etcd集羣實際端點
storageType: S3
backupPolicy:
backupIntervalInSecond: 3600 # 每小時執行一次備份（這裏僅爲示例，可自定義間隔時間）
maxBackups: 5 # 最多保留5個備份文件
s3:
path: "my-s3-bucket/etcd/backups" # 替換爲S3存儲桶路徑
awsSecret: qy-credentials # 替換爲引用qy憑據 secret 的名稱
最後，爲了實現跨地域熱備，可在 etcd 集羣中添加 Learner 節點。Learner 節點作爲非投票成員，不影響集羣性能，其原理是跟隨 Leader 節點同步日誌信息。不過請注意，在 etcd 3.4 版本中，僅支持一個 Learner 節點且串行讀取。
6. 未來可期：展望 etcd 在 Kubernetes 生態系統中持續創新的可能性與挑戰
在 Kubernetes 生態系統中，etcd 作爲核心組件起着不可或缺的作用。隨着雲原生技術的持續演進，etcd 在 Kubernetes 體系中的創新空間及潛在挑戰值得關注。面對未來，etcd 同樣需要應對諸多挑戰，包括如何高效處理海量數據增長、如何更好地兼容異構基礎設施接入，以及如何有效抵禦不斷演變的安全風險。但相信在廣大開發者的共同努力下，etcd 將持續突破，在 Kubernetes 生態系統內推動技術創新，穩固其基石地位。
本文由博客一文多發平臺 OpenWrite 發佈！