為 Kubernetes 運作 etcd 叢集
etcd 是一個一致且高度可用的鍵值儲存區,用作 Kubernetes 的後端儲存區,用於所有叢集資料。
如果您的 Kubernetes 叢集使用 etcd 作為其後端儲存區,請確保您有針對資料的 備份 計劃。
您可以在官方 文件 中找到關於 etcd 的深入資訊。
開始之前
在您按照此頁面中的步驟部署、管理、備份或還原 etcd 之前,您需要了解操作 etcd 叢集的典型預期。請參閱 etcd 文件 以取得更多背景資訊。
重要細節包括
建議在生產環境中執行的最低 etcd 版本為
3.4.22+
和3.5.6+
。etcd 是一個基於領導者的分散式系統。請確保領導者定期及時向所有追隨者發送心跳訊號,以保持叢集穩定。
您應該將 etcd 作為具有奇數成員的叢集執行。
目標是確保不會發生任何資源耗盡。
叢集的效能和穩定性對網路和磁碟 I/O 很敏感。任何資源耗盡都可能導致心跳逾時,進而導致叢集不穩定。不穩定的 etcd 表示沒有選出領導者。在這種情況下,叢集無法對其目前狀態進行任何變更,這表示無法排程任何新的 Pod。
etcd 的資源需求
在資源有限的情況下操作 etcd 僅適用於測試目的。對於在生產環境中部署,需要進階硬體組態。在生產環境中部署 etcd 之前,請參閱 資源需求參考。
保持 etcd 叢集穩定對於 Kubernetes 叢集的穩定性至關重要。因此,為了 保證資源需求,請在專用機器或隔離環境中執行 etcd 叢集。
工具
根據您正在處理的特定結果,您將需要 etcdctl
工具或 etcdutl
工具(您可能需要兩者)。
了解 etcdctl 和 etcdutl
etcdctl
和 etcdutl
是用於與 etcd 叢集互動的命令列工具,但它們的用途不同
etcdctl
:這是主要的命令列用戶端,用於透過網路與 etcd 互動。它用於日常操作,例如管理鍵和值、管理叢集、檢查健康狀態等等。etcdutl
:這是一個管理公用程式,旨在直接操作 etcd 資料檔案,包括在 etcd 版本之間移轉資料、碎片整理資料庫、還原快照以及驗證資料一致性。對於網路操作,應使用etcdctl
。
有關 etcdutl
的更多資訊,您可以參閱 etcd 還原文件。
啟動 etcd 叢集
本節介紹如何啟動單節點和多節點 etcd 叢集。
本指南假設已安裝 etcd
。
單節點 etcd 叢集
僅將單節點 etcd 叢集用於測試目的。
執行以下操作
etcd --listen-client-urls=http://$PRIVATE_IP:2379 \ --advertise-client-urls=http://$PRIVATE_IP:2379
使用旗標
--etcd-servers=$PRIVATE_IP:2379
啟動 Kubernetes API 伺服器。確保
PRIVATE_IP
設定為您的 etcd 用戶端 IP。
多節點 etcd 叢集
為了確保耐用性與高可用性,建議在生產環境中以多節點叢集方式執行 etcd,並定期備份。生產環境中建議使用五個成員的叢集。更多資訊請參閱FAQ 文件。
由於您使用 Kubernetes,您可以選擇在一個或多個 Pod 內以容器方式執行 etcd。kubeadm
工具預設會設定 etcd 靜態 Pod,或者您可以部署獨立的叢集,並指示 kubeadm 使用該 etcd 叢集作為控制平面的後端儲存。
您可以透過靜態成員資訊或動態探索來配置 etcd 叢集。關於叢集化的更多資訊,請參閱 etcd 叢集化文件。
舉例來說,假設有一個由五個成員組成的 etcd 叢集,其用戶端 URL 如下:http://$IP1:2379
、http://$IP2:2379
、http://$IP3:2379
、http://$IP4:2379
和 http://$IP5:2379
。若要啟動 Kubernetes API 伺服器
執行以下操作
etcd --listen-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379 --advertise-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379
請使用旗標
--etcd-servers=$IP1:2379,$IP2:2379,$IP3:2379,$IP4:2379,$IP5:2379
啟動 Kubernetes API 伺服器。請確認
IP<n>
變數已設定為您的用戶端 IP 位址。
具有負載平衡器的多節點 etcd 叢集
若要執行負載平衡 etcd 叢集
- 請設定一個 etcd 叢集。
- 在 etcd 叢集前端配置一個負載平衡器。例如,假設負載平衡器的位址為
$LB
。 - 請使用旗標
--etcd-servers=$LB:2379
啟動 Kubernetes API 伺服器。
保護 etcd 叢集安全
存取 etcd 等同於擁有叢集中的 root 權限,因此理想情況下,只有 API 伺服器應該有權存取它。考量到資料的敏感性,建議僅授予需要存取 etcd 叢集的節點權限。
為了保護 etcd 安全,您可以設定防火牆規則,或使用 etcd 提供的安全性功能。etcd 安全性功能取決於 x509 公開金鑰基礎建設 (PKI)。首先,透過產生金鑰和憑證對來建立安全通訊通道。例如,使用金鑰對 peer.key
和 peer.cert
來保護 etcd 成員之間的通訊安全,並使用 client.key
和 client.cert
來保護 etcd 與其用戶端之間的通訊安全。請參閱 etcd 專案提供的範例腳本,以產生用於用戶端驗證的金鑰對和 CA 檔案。
保護通訊安全
若要配置 etcd 以進行安全的對等通訊,請指定旗標 --peer-key-file=peer.key
和 --peer-cert-file=peer.cert
,並使用 HTTPS 作為 URL 協定。
同樣地,若要配置 etcd 以進行安全的用戶端通訊,請指定旗標 --key-file=k8sclient.key
和 --cert-file=k8sclient.cert
,並使用 HTTPS 作為 URL 協定。以下是用戶端命令使用安全通訊的範例
ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
member list
限制 etcd 叢集的存取
在配置安全通訊之後,請使用 TLS 驗證將 etcd 叢集的存取權限限制為僅限 Kubernetes API 伺服器。
例如,假設金鑰對 k8sclient.key
和 k8sclient.cert
受到 CA etcd.ca
的信任。當 etcd 配置了 --client-cert-auth
以及 TLS 時,它會使用系統 CA 或由 --trusted-ca-file
旗標傳入的 CA 來驗證來自用戶端的憑證。指定旗標 --client-cert-auth=true
和 --trusted-ca-file=etcd.ca
將會限制僅允許具有憑證 k8sclient.cert
的用戶端存取。
一旦正確配置 etcd,只有具有有效憑證的用戶端才能存取它。若要授予 Kubernetes API 伺服器存取權,請使用旗標 --etcd-certfile=k8sclient.cert
、--etcd-keyfile=k8sclient.key
和 --etcd-cafile=ca.cert
來配置它們。
注意
Kubernetes 未規劃 etcd 驗證。更換故障的 etcd 成員
etcd 叢集透過容忍輕微的成員故障來實現高可用性。但是,為了改善叢集的整體健康狀況,請立即更換故障的成員。當多個成員故障時,請逐一更換。更換故障的成員包含兩個步驟:移除故障的成員和新增一個新成員。
雖然 etcd 在內部保留唯一的成員 ID,但建議為每個成員使用唯一的名稱,以避免人為錯誤。例如,假設有一個由三個成員組成的 etcd 叢集。URL 分別為 member1=http://10.0.0.1
、member2=http://10.0.0.2
和 member3=http://10.0.0.3
。當 member1
故障時,請將其更換為 member4=http://10.0.0.4
。
取得故障的
member1
的成員 IDetcdctl --endpoints=http://10.0.0.2,http://10.0.0.3 member list
將顯示以下訊息
8211f1d0f64f3269, started, member1, http://10.0.0.1:2380, http://10.0.0.1:2379 91bc3c398fb3c146, started, member2, http://10.0.0.2:2380, http://10.0.0.2:2379 fd422379fda50e48, started, member3, http://10.0.0.3:2380, http://10.0.0.3:2379
請執行以下任一項操作
- 如果每個 Kubernetes API 伺服器都配置為與所有 etcd 成員通訊,請從
--etcd-servers
旗標中移除故障的成員,然後重新啟動每個 Kubernetes API 伺服器。 - 如果每個 Kubernetes API 伺服器都與單個 etcd 成員通訊,則停止與故障的 etcd 通訊的 Kubernetes API 伺服器。
- 如果每個 Kubernetes API 伺服器都配置為與所有 etcd 成員通訊,請從
停止故障節點上的 etcd 伺服器。除了 Kubernetes API 伺服器之外,可能還有其他用戶端正在造成 etcd 的流量,因此最好停止所有流量,以防止寫入資料目錄。
移除故障的成員
etcdctl member remove 8211f1d0f64f3269
將顯示以下訊息
Removed member 8211f1d0f64f3269 from cluster
新增新成員
etcdctl member add member4 --peer-urls=http://10.0.0.4:2380
將顯示以下訊息
Member 2be1eb8f84b7f63e added to cluster ef37ad9dc622a7c4
在 IP 為
10.0.0.4
的機器上啟動新加入的成員export ETCD_NAME="member4" export ETCD_INITIAL_CLUSTER="member2=http://10.0.0.2:2380,member3=http://10.0.0.3:2380,member4=http://10.0.0.4:2380" export ETCD_INITIAL_CLUSTER_STATE=existing etcd [flags]
請執行以下任一項操作
- 如果每個 Kubernetes API 伺服器都配置為與所有 etcd 成員通訊,請將新加入的成員新增至
--etcd-servers
旗標,然後重新啟動每個 Kubernetes API 伺服器。 - 如果每個 Kubernetes API 伺服器都與單個 etcd 成員通訊,請啟動在步驟 2 中停止的 Kubernetes API 伺服器。然後配置 Kubernetes API 伺服器用戶端,再次將請求路由至停止的 Kubernetes API 伺服器。這通常可以透過配置負載平衡器來完成。
- 如果每個 Kubernetes API 伺服器都配置為與所有 etcd 成員通訊,請將新加入的成員新增至
關於叢集重新配置的更多資訊,請參閱 etcd 重新配置文件。
備份 etcd 叢集
所有 Kubernetes 物件都儲存在 etcd 中。定期備份 etcd 叢集資料對於在災難情境下還原 Kubernetes 叢集非常重要,例如遺失所有控制平面節點。快照檔案包含所有 Kubernetes 狀態和重要資訊。為了確保敏感的 Kubernetes 資料安全,請加密快照檔案。
備份 etcd 叢集可以透過兩種方式完成:etcd 內建快照和磁碟區快照。
內建快照
etcd 支援內建快照。快照可以從一個即時成員建立,使用 etcdctl snapshot save
命令,或者從目前未被 etcd 程序使用的 etcd 資料目錄 複製 member/snap/db
檔案。建立快照不會影響成員的效能。
以下是建立由 $ENDPOINT
服務的鍵值空間快照到檔案 snapshot.db
的範例
ETCDCTL_API=3 etcdctl --endpoints $ENDPOINT snapshot save snapshot.db
驗證快照
以下範例說明了使用 etcdutl
工具驗證快照
etcdutl --write-out=table snapshot status snapshot.db
這應產生類似於以下提供的範例輸出
+----------+----------+------------+------------+
| HASH | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| fe01cf57 | 10 | 7 | 2.1 MB |
+----------+----------+------------+------------+
以下範例說明了使用 etcdctl
工具驗證快照
export ETCDCTL_API=3
etcdctl --write-out=table snapshot status snapshot.db
這應產生類似於以下提供的範例輸出
Deprecated: Use `etcdutl snapshot status` instead.
+----------+----------+------------+------------+
| HASH | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| fe01cf57 | 10 | 7 | 2.1 MB |
+----------+----------+------------+------------+
磁碟區快照
如果 etcd 運行在支援備份的儲存磁碟區上,例如 Amazon Elastic Block Store,則可以透過建立儲存磁碟區的快照來備份 etcd 資料。
使用 etcdctl 選項進行快照
我們也可以使用 etcdctl 提供的各種選項來建立快照。例如
ETCDCTL_API=3 etcdctl -h
將列出 etcdctl 提供的各種選項。例如,您可以透過指定端點、憑證和金鑰來建立快照,如下所示
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>
其中 trusted-ca-file
、cert-file
和 key-file
可以從 etcd Pod 的描述中取得。
擴展 etcd 叢集
擴展 etcd 叢集會以效能為代價來提高可用性。擴展不會提高叢集效能或容量。一般規則是不擴展或縮減 etcd 叢集。不要為 etcd 叢集配置任何自動擴展群組。強烈建議在任何官方支援的規模下,都為生產 Kubernetes 叢集運行靜態的五個成員的 etcd 叢集。
一個合理的擴展是將三個成員的叢集升級為五個成員的叢集,以獲得更高的可靠性。關於如何將成員新增到現有叢集的資訊,請參閱 etcd 重新配置文件。
還原 etcd 叢集
注意
如果您的叢集中有任何 API 伺服器正在運行,您不應嘗試還原 etcd 實例。相反地,請按照以下步驟還原 etcd
- 停止所有 API 伺服器實例
- 還原所有 etcd 實例中的狀態
- 重新啟動所有 API 伺服器實例
Kubernetes 專案也建議重新啟動 Kubernetes 元件(kube-scheduler
、kube-controller-manager
、kubelet
),以確保它們不會依賴某些過時的資料。實際上,還原需要一些時間。在還原期間,關鍵元件將會失去領導者鎖定並自行重新啟動。
etcd 支援從從 major.minor 版本的 etcd 程序取得的快照還原。也支援從不同修補程式版本的 etcd 還原版本。還原操作用於恢復故障叢集的資料。
在開始還原操作之前,必須存在快照檔案。它可以是先前備份操作中的快照檔案,也可以是剩餘的 資料目錄 中的快照檔案。
當使用 etcdutl
還原叢集時,請使用 --data-dir
選項來指定叢集應還原到哪個資料夾
etcdutl --data-dir <data-dir-location> snapshot restore snapshot.db
其中 <data-dir-location>
是在還原過程中將建立的目錄。
以下範例說明了使用 etcdctl
工具進行還原操作
export ETCDCTL_API=3
etcdctl --data-dir <data-dir-location> snapshot restore snapshot.db
如果 <data-dir-location>
與之前的資料夾相同,請在還原叢集之前刪除它並停止 etcd 程序。否則,請變更 etcd 配置並在還原後重新啟動 etcd 程序,以使其使用新的資料目錄:首先將 /etc/kubernetes/manifests/etcd.yaml
的 volumes.hostPath.path
中針對 name: etcd-data
的路徑變更為 <data-dir-location>
,然後執行 kubectl -n kube-system delete pod <name-of-etcd-pod>
或 systemctl restart kubelet.service
(或兩者都執行)。
關於從快照檔案還原叢集的更多資訊和範例,請參閱 etcd 災難復原文件。
如果還原叢集的存取 URL 與先前的叢集不同,則必須相應地重新配置 Kubernetes API 伺服器。在這種情況下,請使用旗標 --etcd-servers=$NEW_ETCD_CLUSTER
而不是旗標 --etcd-servers=$OLD_ETCD_CLUSTER
重新啟動 Kubernetes API 伺服器。將 $NEW_ETCD_CLUSTER
和 $OLD_ETCD_CLUSTER
替換為各自的 IP 位址。如果在 etcd 叢集前端使用負載平衡器,您可能需要更新負載平衡器。
如果大多數 etcd 成員永久故障,則 etcd 叢集被視為故障。在這種情況下,Kubernetes 無法對其目前狀態進行任何變更。雖然排定的 Pod 可能會繼續運行,但無法排定任何新的 Pod。在這種情況下,請恢復 etcd 叢集,並可能重新配置 Kubernetes API 伺服器以解決問題。
升級 etcd 叢集
注意
在開始升級之前,請先備份您的 etcd 叢集。關於 etcd 升級的詳細資訊,請參閱 etcd 升級 文件。
維護 etcd 叢集
關於 etcd 維護的更多詳細資訊,請參閱 etcd 維護 文件。
叢集碎片整理
碎片整理是一項昂貴的操作,因此應盡可能少執行。另一方面,也必須確保任何 etcd 成員都不會超過儲存配額。Kubernetes 專案建議,當您執行碎片整理時,您可以使用諸如 etcd-defrag 之類的工具。
您也可以將碎片整理工具作為 Kubernetes CronJob 執行,以確保定期進行碎片整理。有關詳細資訊,請參閱 etcd-defrag-cronjob.yaml
。
此頁面上的項目參考了提供 Kubernetes 所需功能的第三方產品或專案。Kubernetes 專案作者不對這些第三方產品或專案負責。有關更多詳細資訊,請參閱 CNCF 網站指南。
在建議新增額外的第三方連結的變更之前,您應該閱讀內容指南。