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 read index，绕过了 Raft WAL 的磁盘写入，以实现线性一致性读取。跟随者向领导者请求 read index。领导者的响应表明跟随者是否已与领导者同步。当跟随者的日志是最新的时，本地即可提供多数派读取，无需通过完整的 Raft 协议。因此，读取请求不需要磁盘写入。etcd v3.1 引入了自动领导权转移。当 etcd 领导者收到中断信号时，它会自动将其领导权转移给跟随者。这在集群添加或移除成员时提供了更高的可用性。

etcd v3.2 (2017 年夏)

etcd v3.2 专注于稳定性。其客户端包含在 Kubernetes v1.10、v1.11 和 v1.12 中。etcd 团队仍然通过反向移植所有 bug 修复积极维护该分支。此版本引入了 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 标志。默认情况下，重新加入的跟随者会加快选举计时器的跳动，以加速其初始集群引导。例如，启动的跟随者节点在开始选举之前只等待 200ms，而不是完整的选举超时 1 秒。理想情况下，在 200ms 内，它会收到领导者的心跳，并立即作为跟随者加入集群。然而，如果发生网络分区，心跳可能会丢失，从而触发领导权选举。来自已分区节点的投票请求会非常具有破坏性。如果它包含更高的 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 以前维护一个单独的 freelist DB 来跟踪事务后不再使用并释放的页面，以便后续事务可以重用它们。然而，事实证明持久化 freelist 需要大量磁盘空间，并给 Kubernetes 工作负载带来高延迟。特别是在频繁进行快照并包含大量读取事务时，etcd 数据库大小会迅速从 16 MB 增长到 4 GB。etcd v3.3 禁用了 freelist 同步，并在重启时重建 freelist。开销非常小，大多数用户几乎无法察觉。有关此问题的更多信息，请参阅“数据库空间超出”问题。

etcd v3.4 及以后

etcd v3.4 致力于改进操作体验。它增加了Raft pre-vote 功能，以提高领导者选举的健壮性。当节点隔离（例如网络分区）时，该成员会开始选举，以增加的 Raft 任期请求投票。当领导者收到带有更高任期的投票请求时，它会降级为跟随者。使用 pre-vote，Raft 会额外运行一个选举阶段，以检查候选者是否能获得足够的投票赢得选举。隔离的跟随者的投票请求会被拒绝，因为它不包含最新的日志条目。

etcd v3.4 增加了Raft learner，它作为无投票权成员加入集群，但仍然接收领导者的所有更新。添加 learner 节点不会增加多数派的大小，因此在成员重新配置期间提高了集群可用性。它仅作为备用节点，直到被提升为有投票权成员。此外，为了处理意外升级失败，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 中的领导作用。

• ←上一篇
• 下一篇→