什么是 etcd？

与所有分布式工作负载一样，容器化工作负载具有复杂的管理要求，并且随着工作负载的扩展而变得更加复杂。Kubernetes 通过协调所有集群的配置、部署、服务发现、负载平衡、作业调度和运行状况监控等任务，简化了这些工作负载的管理流程，这些集群可以在多个位置的多台计算机上运行。

但为了实现这种协调，Kubertes 需要一个数据存储库，能够在任何给定时间点提供有关系统状态（所有集群和 Pod 以及其中的应用程序实例）的单一、一致的事实来源。etcd 是用于创建和维护此事实版本的数据存储库。

对于 Cloud Foundry（开源多云平台即服务 (PaaS)）来说，etcd 也发挥着类似的作用，是在任何分布式应用集群中协调关键系统和元数据的可行选择。名称 "etcd" 来自 Linux 目录结构中的命名约定：在 UNIX 中，单个系统的所有系统配置文件都包含在名为 "/etc;" 的文件夹中，"d" 代表“分布式”。

用作保持分布式工作负载运行的数据基础并非易事。但 etcd 是专为这项任务而构建的，从头开始设计，具有以下特征：

• 完全复制：etcd 集群中的每个节点都可以访问完整数据存储库。
  
  
• 高可用性：etcd 设计为无单点故障，并能够宽容硬件故障和网络分区。
  
  
• 可靠一致：每次数据“读取”都会返回所有集群中的最新数据“写入”。
  
  
• 快速：etcd 的基准测试速度为每秒 10,000 次写入。
  
  
• 安全：etcd 支持自动传输层安全 (TLS) 和可选的安全套接字层 (SSL) 客户端证书身份验证。由于 etcd 用于存储重要且高度敏感的配置数据，因此，管理员应在部署中实施基于角色的访问控制，并确保与 etcd 交互的团队成员仅拥有执行工作所需的最低权限级别。
  
  
• 简单：任何应用程序，从简单的 Web 应用程序到高度复杂的容器编排引擎（如 Kubernetes），都可以使用标准的 HTTP/JSON 工具在 etcd 中读取或写入数据。

请注意，由于 etcd 的性能严重依赖于存储磁盘速度，因此，强烈建议在 etcd 环境中使用 SSD。

etcd 建立在 Raft 共识算法之上，以确保集群中所有节点的数据存储一致性，这是容错分布式系统的基石。

Raft 通过一个选举的领导者 节点来实现这种一致性，该节点管理集群中其他节点（称为跟随者）的复制。领导者接受来自客户端的请求，然后将其转发到跟随者节点。一旦领导者确定大多数 跟随者节点已将每个新请求存储为日志条目，它就会将该条目应用于其本地状态机并将该执行的结果（“写入”）返回给客户端。如果跟随者崩溃或网络数据包丢失，领导者将重试，直到所有跟随者一致地存储所有日志条目。

如果跟随者节点未能在指定的时间间隔内收到来自领导者的消息，则将举行选举以选择新的领导者。跟随者宣布自己为候选者，其他跟随者根据相关可用性对该节点或任何其他节点进行投票。一旦选出新的领导人，它就会开始管理复制，这一过程将重复进行。通过此过程，所有 etcd 节点都能获得数据存储库的具有高可用性且一致复制的副本。

etcd 包含在核心 Kubernetes 组件中，并作为创建功能齐全、容错能力强的 Kubernetes 集群的主要键值存储库。Kubernetes API 服务器将每个集群的状态数据存储在 etcd 中。Kubernetes 使用 etcd 的“监视”功能来监控这些数据，并在发生变更时自行重新配置。“监视”功能存储了代表集群实际状态和理想状态的数值，并能在两者出现偏差时做出响应。

有关 Kubernetes 如何管理集群、服务、工作节点的高层次概述，请观看视频“Kubernetes 详解”：

etcd 由负责设计 CoreOS Container Linux 的同一团队创建，CoreOS Container Linux 是一种广泛使用的容器操作系统，可以大规模高效运行和管理。他们最初在 Raft 上构建 etcd 来同时协调 Container Linux 的多个副本，确保应用程序不间断的正常运行。

2018 年 12 月，该团队将 etcd 捐赠给了云原生计算基金会 (CNCF)，该基金会是一个中立的非营利组织，将 etcd 的源代码、域、托管服务、云基础设施和其他项目财产作为开源资源进行维护，供基于容器的云开发社区使用。CoreOS 已与 Red Hat 合并。

已经开发了其他数据库来管理跨分布式应用程序集群之间的坐标信息。最常与 etcd 进行比较的两个工具是 ZooKeeper 和 Consul。

ZooKeeper 最初是为了协调 Apache Hadoop 集群之间的配置数据和元数据而创建的。（Apache Hadoop 是一个开源框架或应用程序集合，用于在商用硬件集群上存储和处理大量数据。）ZooKeeper 比 etcd 更早出现，从使用 ZooKeeper 中吸取的经验教训影响了 etcd 的设计。

因此，etcd 拥有 ZooKeeper 不具备的一些重要功能。例如，与 ZooKeeper 不同，etcd 能够执行以下操作：

• 允许动态重新配置集群成员资格。
  
  
• 在高负载下执行读/写操作时保持稳定。
  
  
• 维护多版本并发控制数据模型。
  
  
• 提供可靠的密钥监控，绝不会在未发通知的情况下丢弃事件。
  
  
• 使用将连接与会话分离的并发基元。
  
  
• 支持多种语言和框架（ZooKeeper 自定义了 Jute RPC 协议，支持有限的语言绑定）。

Consul 是一种用于分布式系统的服务网络解决方案，其功能介于 etcd 和用于 Kubernetes 的 Istio 服务网格之间。与 etcd 一样，Consul 包括基于 Raft 算法的分布式键值存储库，并支持 HTTP/JSON 应用程序编程接口 (API)。两者都提供动态集群成员资格配置，但 Consul 对配置数据的多个并发版本的控制不够强，并且能够可靠工作的最大数据库大小也较小。

与 etcd 一样，Redis 是一个开源工具，但它们的基本功能不同。

Redis 是一个内存数据存储，可以用作数据库、缓存或消息代理。与 etcd 相比，Redis 支持更广泛的数据类型和结构，并且具有更高的读/写性能。

但 etcd 具有卓越的容错能力、更强大的故障转移和持续的数据可用性功能，最重要的是，etcd 将所有存储的数据持久保存到磁盘上，这本质上牺牲了速度来换取更高的可靠性并保证一致性。由于这些原因，Redis 更适合用作分布式内存缓存系统，而不是存储分布式系统配置信息。