etcd：当前状态和未来路线图

etcd 是一个分布式键值存储，它提供了一种可靠的方式来管理分布式系统的协调状态。etcd 于 2013 年 6 月由 CoreOS（2018 年成为 Red Hat 的一部分）首次发布。自 2014 年被 Kubernetes 采用以来，etcd 已成为 Kubernetes 集群管理软件设计的基础部分，etcd 社区也呈指数级增长。etcd 目前已被多家公司用于生产环境，包括大型云提供商环境，如 AWS、Google Cloud Platform、Azure 以及其他本地 Kubernetes 实现。CNCF 目前拥有 32 个符合要求的 Kubernetes 平台和发行版，所有这些都使用 etcd 作为数据存储。

在这篇博文中，我们将回顾最新 etcd 版本中取得的一些里程碑，并介绍 etcd 的未来路线图。请在邮件列表 etcd-dev@googlegroups.com 上分享您对重要功能的想法和反馈。

etcd，2013 年

2014 年 6 月，Kubernetes 发布，etcd 作为所有主控状态的后端存储。Kubernetes v0.4 使用了当时处于 alpha 阶段的 etcd v0.2 API。随着 Kubernetes 在 2015 年达到 v1.0 里程碑，etcd 稳定了其 v2.0 API。Kubernetes 的广泛采用导致 etcd 的可伸缩性要求急剧增加。为了处理大量工作负载和不断增长的规模要求，etcd 于 2016 年 6 月发布了 v3.0 API。Kubernetes v1.13 最终放弃了对 etcd v2.0 API 的支持，并采用了 etcd v3.0 API。下表直观地展示了 etcd 和 Kubernetes 的发布周期。

etcd v3.1，2017 年初

etcd v3.1 的功能在版本升级期间提供了更好的读取性能和更高的可用性。鉴于 etcd 至今在生产中的高使用率，这些功能对用户非常有用。它实现了 Raft 读取索引，绕过了 Raft WAL 磁盘写入，实现了线性化读取。追随者从领导者请求读取索引。领导者的响应表明追随者是否与领导者同步。当追随者的日志是最新的时，仲裁读取在本地提供，而无需通过完整的 Raft 协议。因此，读取请求不需要磁盘写入。etcd v3.1 引入了自动领导者转移。当 etcd 领导者接收到中断信号时，它会自动将其领导者身份转移给一个追随者。这在集群添加或删除成员时提供了更高的可用性。

etcd v3.2 (2017 年夏季)

etcd v3.2 专注于稳定性。其客户端已随 Kubernetes v1.10、v1.11 和 v1.12 发布。etcd 团队仍然通过回溯所有错误修复来积极维护该分支。此版本引入了 gRPC 代理以支持、监视并将所有监视事件广播合并为一个 gRPC 流。这些事件广播每秒可达一百万次。

etcd v3.2 还引入了更改，例如 `snapshot-count` 默认值从 10,000 更改为 100,000。通过更高的快照计数，etcd 服务器在压缩旧条目之前，会在内存中保留 Raft 条目更长时间。etcd v3.2 的默认配置显示更高的内存使用量，同时为缓慢的追随者提供了更多赶上的时间。这是减少快照发送频率和增加内存使用量之间的权衡。用户可以使用较低的 `etcd --snapshot-count` 值来减少内存使用量，或者使用较高的 `snapshot-count` 值来提高慢速追随者的可用性。

etcd v3.2.19 中回溯的另一个新功能是 `etcd --initial-election-tick-advance` 标志。默认情况下，重新加入的追随者会快进选举计时器，以加快其初始集群引导。例如，启动的追随者节点只等待 200 毫秒，而不是完整的选举超时 1 秒，然后才开始选举。理想情况下，在 200 毫秒内，它会收到领导者的心跳并立即作为追随者加入集群。然而，如果发生网络分区，心跳可能会丢失，从而触发领导者选举。来自分区节点的投票请求具有很大的破坏性。如果它包含较高的 Raft 任期，当前领导者将被迫下台。将 “initial-election-tick-advance” 设置为 false，重新加入的节点在扰乱集群之前有更多机会接收领导者心跳。

etcd v3.3 (2018 年初)

etcd v3.3 继续秉承稳定性的主题。其客户端包含在 Kubernetes v1.13 中。以前，etcd 客户端在网络断开时会不加思索地重试，没有任何退避或故障转移逻辑。客户端经常卡在分区节点上，影响了多个生产用户。v3.3 客户端负载均衡器现在使用 gRPC 健康检查协议维护一个不健康端点列表，在瞬时断开连接和网络分区时进行更高效的重试和故障转移。此功能已回溯到 etcd v3.2，也包含在 Kubernetes v1.10 API 服务器中。etcd v3.3 还提供了更可预测的数据库大小。etcd 过去维护一个单独的空闲列表数据库来跟踪不再使用并在事务后释放的页面，以便后续事务可以重用它们。然而，事实证明，持久化空闲列表需要高磁盘空间，并为 Kubernetes 工作负载引入高延迟。特别是当频繁快照和大量读取事务时，etcd 数据库大小迅速从 16 MB 增长到 4 GB。etcd v3.3 禁用空闲列表同步，并在重启时重建空闲列表。开销非常小，大多数用户几乎无法察觉。有关此问题的更多信息，请参阅“数据库空间超出”问题。

etcd v3.4 及更高版本

etcd v3.4 专注于改善操作体验。它增加了 Raft 预投票功能，以提高领导者选举的稳健性。当一个节点被隔离（例如网络分区）时，该成员将开始选举，请求带有增加的 Raft 术语的投票。当领导者收到具有更高术语的投票请求时，它会退位为追随者。通过预投票，Raft 运行一个额外的选举阶段，以检查候选人是否能获得足够的票数来赢得选举。隔离的追随者的投票请求被拒绝，因为它不包含最新的日志条目。

etcd v3.4 增加了Raft 学习者，它作为非投票成员加入集群，仍然接收领导者的所有更新。添加学习者节点不会增加仲裁大小，因此在成员配置重组期间提高了集群可用性。它只作为备用节点，直到被提升为投票成员。此外，为了处理意外的升级失败，v3.4 引入了etcd 降级功能。

etcd v3 存储使用多版本并发控制模型来保留键更新作为事件历史记录。Kubernetes 运行压缩以丢弃不再需要的事件历史记录，并回收存储空间。etcd v3.4 将改进此存储压缩操作，提高后端大型读取事务的并发性，并优化 Kubernetes 用例的存储提交间隔。

为了进一步改进 etcd 客户端负载均衡器，v3.4 负载均衡器已重写，以利用新引入的 gRPC 负载均衡 API。通过利用 gRPC，etcd 客户端负载均衡器代码库大大简化，同时保留了与 v3.3 实现的功能奇偶校验，并通过在健康端点之间进行轮询请求来改进整体负载均衡。有关更多详细信息，请参阅客户端架构。

此外，etcd 维护者将继续改进 Kubernetes 测试框架：用于可伸缩性测试的 kubemark 集成，带 etcd 的 Kubernetes API 服务器一致性测试以提供发布建议和版本偏差策略，为每个云提供商指定一致性测试要求等。

etcd 加入 CNCF

etcd 现在在 etcd-io 有了一个新家，并作为孵化项目加入了 CNCF。

与 Kubernetes 的协同努力推动了 etcd 的发展。没有社区的反馈和贡献，etcd 就不可能达到其成熟度和可靠性。我们期待 etcd 作为一个开源项目继续发展，并很高兴与 Kubernetes 和更广泛的 CNCF 社区合作。

最后，我们要感谢所有贡献者，特别感谢 Xiang Li 在 etcd 和 Kubernetes 中的领导作用。

• ←上一篇
• 下一篇→