etcd 目前为 CNCF 孵化项目

etcd 是一种分布式键值存储方式，为分布式系统的协调状态提供可靠的管理方式。etcd 由 CoreOS 于 2013 年 6 月首次发布（2018 年起作为 Red Hat 的组成部分）。自 2014 年被 Kubernetes 采用以来，etcd 成为 Kubernetes 集群管理软件设计，etxd 社区出现了指数级增长。目前，etcd 在多家公司被用于生产环境，包括如 AWS、Google Cloud Platform、Azure 等大型云提供商，以及其他本地 Kubernetes 安装启用。CNCF 目前已经拥有 32 个一致性 Kubernetes 平台和分布式系统，全部采用 etcd 作为数据存储方式。

既然 etcd 已经正式加入 CNCF 孵化项目，我们想要回顾一下 etcd 最新发布中所实现的重大里程碑事件，并分享一下 etcd 的未来发展路线图。我们很乐意倾听您对重要功能的想法和反馈意见，请通过以下电子邮箱联系我们，etcd-dev@googlegroups.com。

etcd，2014

2014 年 6 月，Kubernetes 发布了 etcd，作为全部主状态的后备存储器。初期阶段，Kubernetes v0.4 使用了 etcd v0.2 API。2015 年 Kubernetes 实现 v1.0 这一里程碑时， etcd 稳定了其 v2.0 API。对 Kubernetes 的广泛采用导致了对 etcd 可伸缩性需求的急剧增加。为了应对巨大的工作量和不断增长的伸缩需求，etcd 于 2016 年 6 月发布了 v3.0 API。2018 年 12 月发布了 Kubernetes v1.13，最终终止支持 etcd v2.0 API 并采用了 etcd v3.0 API。下表列出了 etcd 和 Kubernetes 的发布周期视觉快照。

etcd v3.1，2017 年初

etcd v3.1 功能在版本升级期间提供了更好的阅读效率和可用性——实现了 etcd 在生产中的高效实用，这对用户来说至关重要。它还实现了 Raft 读取指数，绕开了针对线性化读取的 Raft WAL 盘写入：跟随者向指挥者请求读取指数，然后指挥者的响应指示跟随者是否与指挥者一样先进。当跟随者的日志随日期更新时，Quorum 读取在本地伺服，而无需通过全部 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” 默认值从 10000 增加至 100000。有了更高的快照计数，etcd 服务器在压缩旧条目前，会在更长时间内保留 Raft 内存条目。在给慢速追随者更多时间的情况下，etcd v3.2 默认配置显示了更高的内存使用量。这是较低频率快照发送和更高内存使用量之间的折中。用户可以设置较低的–snapshot-count 值以降低内存使用量，或较高的 snapshot-count 值以提升慢速追随者的可用性。

另一个后向移植给 etcd v3.2.19 的新功能是 --initial-election-tick-advance 标记。默认情况下，重新加入的追随者的快进选举会标记加速其初始集群引导程序。例如，开始选举前，开始的追随者节点仅等候 200ms 而非一秒的全选举超时。理想情况下，在 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 曾经保留了单独的自由列表 DB 以追踪不再使用的页面和交易后的空闲页面，以便后续交易可以再次使用。然而，结果是保存的自由列表需要大量磁盘空间并引入了 Kubernetes 工作量的高延迟。尤其是有附带大量读取交易的频繁快照时，etcd 数据库大小快速从 16 MB 增长到 4 GB。etcd v3.3 禁用了自由列表同步并在重启时重建了自由列表。系统开销时间短，绝大多数用户难以察觉。关于这方面的更多信息，请查看“超出数据库空间”问题。

etcd v3.4 及以上

etcd v3.4 致力于提升操作体验。.增加了 Raft 预投票功能以提升指挥选举的稳健性。当节点被隔离（如网络分区的后果），该成员将启动以增多的 Raft 条件请求投票的选举。当指挥者收到更高条件的投票请求时，它将降级为追随者。凭借预投票，Raft 运行了额外的选举阶段以检查候选者是否能获得足够的投票赢得选举。隔离追随者的投票请求被拒绝，因为其不包含最新的日志条目。

etcd v3.4 增加了 Raft 学习者，作为非投票成员加入集群，但仍接受来自指挥者的全部更新。增加学习者节点不会使 Quorum 变大，从而在成员重置期间提升可用性。它只作为待机节点，直到提升为投票成员。还有，为处理意外的升级失败， v3.4 还引入了 etcd 降级功能。

etcd v3 存储使用了多版本并行控制模式，以将关键的更新保存为事件历史记录。Kubernetes 进行压缩，以删除不再需要的事件历史记录，并回收再利用存储空间。etcd v3.4 将优化此存储压缩操作，针对大量读取交易提高后端并行，并为 Kubernetes 使用案例优化存储提交间隔。

为进一步提升 etcd 客户端负载均衡器，对 v3.4 均衡器进行了重写，以利用新引入的 gRPC 负载均衡 API。这使得我们可以大幅简化 etcd 客户端负载均衡器代码库，同时保持功能与 v3.3 同效，通过健康终端节点间的循环请求提升所有负载均衡。更多详细信息，参见客户端架构。

此外，etcd 维护人员将继续提升 Kubernetes 测试框架：kubemark 可伸缩性集成测试、etcd Kubernetes API 服务器一致性测试，提供版本推荐和版本偏斜策略，为每个云提供商指定一致性测试要求等。

与 Kubernetes 开展的协同工作推动了 etcd 的发展。无需社区反馈和贡献，etcd 无法实现其当前所及的成熟度和可靠性。我们希望继续推进 etcd 这个开源项目的发展，非常高兴能与 Kubernetes 以及更广泛的 CNCF 社区合作。

最后，我们想感谢所有贡献者，特别感谢 Xiang Li 对于 etcd 和 Kubernetes 的领导。

作者介绍：

Joe Betz

Joe Betz 是 etcd Google 云的领先软件工程师，也是 etcd 项目维护人员，Joe 直接负责 GKE etcd 团队的健康和稳定，通过开源贡献带领推动 etcd 发展。他积极贡献于 Kubernetes，专注于 etcd 界面层，有时会参与原料药机械其他领域的开发。他还以 Kubernetes 1.8 分支补丁管理员的身份服务于社区。

本文转载自 AWS 技术博客。

原文链接：

https://amazonaws-china.com/cn/blogs/china/etcd-cncf-incubating-project-status-roadmap/