什么是 etcd？

etcd 是一种开源的分布式键值存储库，用于保存和管理分布式系统保持运行所需的关键信息。最值得注意的是，它可以管理 Kubernetes（流行的容器编排平台）的配置数据、状态数据和元数据。

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

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

对于 Cloud Foundry（链接位于 ibm.com 外部，这是一个开源的多云平台即服务 (PaaS)），etcd 发挥着类似的作用，并且可用于跨任何分布式应用集群来协调关键系统和元数据。 “etcd”这个名字源自 Linux 目录结构中的命名约定：在 UNIX 中，单个系统的所有系统配置文件都包含在一个名为“/etc”的文件夹中；“d”代表“分布式”。

观看视频“什么是 etcd？”(6:09)，以深入了解 etcd：

为何选择 etcd？

etcd 作为保持分布式工作负载运行的数据支柱，它的作用不容小觑。 etcd 正是为这个任务而构建的，它采用全新的设计，具有以下特性：

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

请注意，由于 etcd 的性能在很大程度上取决于存储磁盘的速度，因此强烈建议在 etcd 环境中使用 SSD。有关此 etcd 存储要求和其他存储要求的更多信息，请查看“使用 Fio 判断您的存储器是否足以运行 etcd”。

Raft 共识算法

etcd 基于 Raft 共识算法而构建，可确保集群中所有节点之间的数据存储一致性 - 这就是具有容错能力的分布式系统的目标。

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

如果某个跟随节点在指定的时间间隔内未能收到来自领导节点的消息，那么将推选出新的领导节点。该跟随节点会将自己声明为候选者，其他跟随节点则会根据其可用性为它或任何其他节点投票。一旦选出了新的领导节点，该节点就会开始管理复制，并且这个过程会自行重复。这个过程让所有 etcd 节点能够维护高度可用且一致的数据存储副本。

etcd 与 Kubernetes

etcd 是 Kubernetes 的核心组件之一，充当主要键值存储库，用于创建可正常运行且具有容错能力的 Kubernetes 集群。 Kubernetes API 服务器会将每个集群的状态数据都存储在 etcd 中。 Kubernetes 使用 etcd 的“观察”功能来监控这些数据，并在发生变化时自行重新配置。 “观察”功能会存储代表集群实际状态和理想状态的值，并且可以在这两种状态不同时作出响应。

有关 Kubernetes 如何管理集群、服务和工作程序节点的简要概述，请观看我们的视频“Kubernetes 详解”：

CoreOS 与 etcd 的历史记录和维护

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

2018 年 12 月，该团队将 etcd 贡献给云原生计算基金会 (CNCF)，这是一个中立的非营利性组织，以基于容器的云开发社区的开源资源形式维护 etcd 的源代码、域、托管服务、云基础架构和其他项目财产。 CoreOS 已被 Red Hat 并购。

etcd、ZooKeeper 与 Consul

为了管理分布式应用集群之间的协调信息，人们已开发出了其他数据库。 ZooKeeper 和 Consul 是可与 etcd 相提并论的两个最常见的工具。

ZooKeeper

ZooKeeper 的创建目的是协调 Apache Hadoop 集群中的配置数据和元数据。（Apache Hadoop（链接位于 ibm.com 外部）是一个开源框架或应用集合，用于在商业硬件集群上存储和处理大量数据。） ZooKeeper 的历史比 etcd 更悠久；ZooKeeper 的使用经验影响了 etcd 的设计。

因此，etcd 可提供一些 ZooKeeper 无法提供的重要功能。例如，etcd 可执行以下 ZooKeeper 无法执行的操作：

支持动态重新配置集群成员资格。
在高负载的情况下稳定地执行读/写操作。
维护多版本并发控制数据模型。
提供可靠的关键监控，未发出通知的情况下绝不会丢弃事件。
使用将连接与会话分离的并发原语。
支持广泛的语言和框架（ZooKeeper 具有自己的定制 Jute RPC 协议，只支持有限的语言绑定）。

Consul

Consul 是用于分布式系统的服务网络解决方案，其功能介于 etcd 与 Kubernetes 的 Istio 服务网格之间。与 etcd 一样，Consul（链接位于 ibm.com 外部）包含一个基于 Raft 算法的分布式键值存储库，并支持 HTTP/JSON 应用程序编程接口 (API)。它们都提供动态集群成员资格配置，但 Consul 对多个并发版本的配置数据没有那么强的控制，并且在稳定工作时使用的最大数据库更小。

etcd 与 Redis

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

Redis 是一种内存中数据存储库，可用作数据库、缓存或消息代理。 Redis 支持的数据类型和结构比 etcd 多，其读/写性能也快得多。

但是，etcd 具有超强的容错能力以及更强的故障转移和持续数据可用性能力，最重要的是，etcd 将所有数据都持久存储在磁盘上，这从本质上是牺牲速度来提升可靠性和保证一致性。因此，Redis 更适合用作分布式内存缓存系统，而不是存储分布式系统配置信息。