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

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

在这篇博文中，我们将回顾最新 etcd 版本中取得的一些里程碑，并介绍 etcd 的未来路线图。请在邮件列表中分享您认为重要的功能的想法和反馈：[email protected]。

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。通过利用 gPRC，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 中的领导作用。

• ←上一篇
下一篇→