如何解析K8s中的Etcd

這篇文章將為大家詳細講解有關如何解析K8s中的Etcd，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

一、介紹

Etcd被形容為Kubernetes集群的大腦，是 Kubernetes的關鍵組件，因為它存儲了集群的整個狀態：其配置，規格以及運行中的工作負載的狀態。

在Kubernetes世界中，etcd用作服務發現的后端，并存儲集群的狀態及其配置。

Etcd被部署為一個集群，幾個節點的通信由Raft算法處理。在生產環境中，集群包含奇數個節點，并且至少需要三個。

關于 etcd

 etcd。名稱 “etcd” 源自兩個想法，即 unix “/etc” 文件夾 和 “d” 分布式系統。“/etc” 文件夾是用于存儲單個系統的配置數據的位置，而 etcd 用于存儲大規模分布式的配置信息。因此，分配了 “d” 的 “/etc” 就是 “etcd”。

etcd 被設計為大型分布式系統的通用基板。這些大型系統需要避免裂腦操作，并且愿意犧牲可用性來實現此目的。 etcd 以一致且容錯的方式存儲元數據。 etcd 集群旨在提供具有穩定性、可靠性、可伸縮性和性能的鍵值存儲。

分布式系統將 etcd 用作配置管理、服務發現和協調分布式工作的一致鍵值存儲組件。許多組織在生產系統上使用 etcd，例如容器調度程序、服務發現服務和分布式數據存儲。使用 etcd 的常見分布式模式包括領導者選舉、分布式鎖和監視機器活動狀態等。

與 ZooKeeper

ZooKeeper 解決了與 etcd 相同的問題：分布式系統協調和元數據存儲。但是， etcd 踩在前人的肩膀上，其參考了 ZooKeeper 的設計和實現經驗。從 Zookeeper 汲取的經驗教訓無疑為 etcd 的設計提供了支撐，從而幫助其支持 Kubernetes 等大型系統。對 Zookeeper 進行的 etcd 改進包括：

• 動態重新配置集群成員

• 高負載下穩定的讀寫

• 多版本并發控制數據模型

• 可靠的鍵值監控

• 租期原語將 session 中的連接解耦

• 用于分布式共享鎖的 API

此外，etcd 開箱即用地支持多種語言和框架。Zookeeper 擁有自己的自定義Jute RPC 協議，該協議對于 Zookeeper 而言是完全唯一的，并限制了其受支持的語言綁定，而 etcd 的客戶端協議則是基于 gRPC 構建的，gRP 是一種流行的 RPC 框架，具有 go，C ++，Java 等語言支持。同樣，gRPC 可以通過 HTTP 序列化為 JSON，因此即使是通用命令行實用程序（例如curl）也可以與之通信。由于系統可以從多種選擇中進行選擇，因此它們是基于具有本機工具的 etcd 構建的，而不是基于一組固定的技術圍繞 etcd 構建的。

在考慮功能，支持和穩定性時，etcd 相比于 Zookeeper，更加適合用作一致性的鍵值存儲的組件。

二、Kubernetes 中的 Etcd

在Kubernetes集群的上下文中，etcd實例可以作為Pod部署在master節點上（這是我們將在本文中使用的示例）。

關于如何解析K8s中的Etcd就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。