揭秘！KubeSphere 背後的“超級大腦”：etcd 的魅力與力量

發表於2024-02-24
作者：尹珉，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 釋出！

相關文章