宣布etcd 3.4

作者: Gyuho Lee(Amazon Web服务,@ 久保 ),胡静怡(Google,@ 静宜 )

etcd 3.4着重于稳定性,性能和易操作性,具有预投票和非投票成员等功能以及对存储后端和客户端平衡器的改进。

请参阅 更新日志 有关更改的完整列表。

更好的存储后端

etcd v3.4包括针对大规模Kubernetes工作负载的许多性能改进。

In particular, etcd experienced performance issues with a large number of concurrent read transactions even when there is no write (e.g. “read-only range request ... took too long to execute” )。 以前 ly, the storage backend commit operation on pending writes blocks incoming read transactions, even when there was no pending write. Now, the commit 不阻止读取 从而提高了长期运行的读取事务的性能。

我们进一步做了 后端读取事务完全并发 。以前,正在进行的长时间运行的读取事务会阻止写入和即将进行的读取。通过此更改,在长时间运行读取的情况下,写入吞吐量增加了70%,P99写入延迟减少了90%。我们也跑了 在GCE上进行Kubernetes 5000节点可扩展性测试 有了这一变化,并观察到了类似的改进。例如,在测试一开始就有很多长期运行的“ LIST Pod”的情况下,“ POST clusterrolebindings”的P99延迟为 减少了97.4% .

在租用存储方面进行了更多改进。我们增强了 租约到期/撤销履行 通过更有效地存储租赁对象 租约查找操作无阻塞 当前的租赁授予/撤销操作。 和 etcd v3.4的介绍 租赁检查站 作为一项实验功能,可以通过共识来保留剩余的生存时间值。这确保了短暂的租赁对象在领导选举后不会自动更新。当生存时间值较大时(例如, 1小时TTL在Kubernetes用例中永不过期 )。

改进的木筏投票流程

etcd服务器实现 筏共识算法 用于数据复制。 Raft是基于领导者的协议。数据从领导者复制到跟随者;跟随者将建议转发给领导者,领导者决定要提交或不提交的内容。一旦集群的法定人数同意,Leader会保留并复制条目。集群成员选出一个领导者,所有其他成员成为跟随者。当选领导人定期发送心跳到它的追随者保持其领先地位,并期望从每个跟随反应,跟踪其进展情况。

在最简单的形式中,当筏筏领导者收到更高条件的消息而没有任何进一步的集群范围的运行状况检查时,其领导者就会下台。此行为可能会影响整个群集的可用性。

例如,一个片状(或重新加入)的成员掉进和退出,并开始竞选。该成员以较高的术语结尾,忽略所有较低术语的传入消息,并发送较高术语的消息。领导者收到较高期限的消息时,将恢复为跟随者。

当存在网络分区时,这将更具破坏性。每当分区节点恢复其连接性时,它都可能触发领导者重新选举。为了解决这个问题,etcd Raft引入了一个新的节点状态候选对象, 投票前功能 。候选候选人首先询问其他服务器是否足够最新以获取投票。只有能够获得多数选票,它才会增加任期并开始选举。这一额外阶段总体上提高了领导人选举的稳健性。只要领导者保持与同事的法定人数的连通性,就可以帮助其保持稳定。

类似地,当重新启动的节点未及时接收到领导者心跳时(例如由于网络速度缓慢),etcd的可用性可能会受到影响,从而触发领导者选举。以前,etcd在服务器启动时快速前进选举滴答声,仅剩下一个滴答声用于领导者选举。例如,当选超时是1秒,从动只开始一次选举之前等待前导触点100毫秒。这样就不必等待选举超时,从而加快了初始服务器的启动速度(例如,选举是在100毫秒而不是1秒的时间内触发的)。提前选择时间对于选择超时较大的跨数据中心部署也很有用。但是,在许多情况下,可用性比最初的领导者选举速度更为关键。现在通过重新加入节点,以确保更好的可用性 调整选举滴答声 剩下一个以上的滴答声,因此领导者有更多时间来防止破坏性的重启。

木筏非投票会员,学习者

成员资格重新配置的挑战在于,它通常会导致仲裁组大小更改,这很容易导致群集不可用。即使不会更改仲裁,具有成员资格更改的群集也更有可能遇到其他潜在问题。为了提高重新配置的可靠性和可信度,etcd 3.4版本引入了一个新角色-学习器。

一个新的etcd成员没有初始数据就加入了集群,向领导者请求所有历史更新,直到它赶上领导者的日志为止。这意味着领导者的网络更有可能过载,从而阻止或丢弃领导者的心跳给追随者。在这种情况下,关注者可能会经历选举超时并开始新的领导者选举。也就是说,拥有新成员的集群更容易受到领导人选举的影响。领导者的选举以及随后向新成员的更新传播都容易导致一段时间的集群不可用(请参阅 图1 )。

learner-figure-1

The worst case is a misconfigured membership add. Membership reconfiguration in etcd is a two-step process: etcdctl member add with peer URLs, 和 starting a new etcd to join the cluster. That is, member add command is applied whether the peer URL value is invalid or not. If the first step is to apply the invalid URLs 和 change the quorum size, it is possible that the cluster already loses the quorum until the new node connects. Since the node with invalid URLs will never become online 和 there’s no leader, it is impossible to revert the membership change (see 图2 )。

learner-figure-2

当存在分区节点时,这变得更加复杂(请参见 设计文件 了解更多)。

为了解决这种故障模式,etcd引入了 新节点状态“学习者”,它以无表决权的成员身份加入集群,直到赶上领导者的日志为止。这意味着学习者仍会从领导者那里收到所有更新,而这并不计入仲裁人数,领导者使用仲裁来评估对等活动。在提升之前,学习者仅充当备用节点。对仲裁的这种宽松要求在成员重新配置和操作安全期间提供了更好的可用性(请参阅 图3 )。

learner-figure-3

我们将进一步提高学习者的鲁棒性,并探索自动推广的机制,以使操作更轻松,更可靠。请阅读我们的 学习者设计文档运行时配置文档 用于用户指南。

新客户平衡器

etcd旨在容忍各种系统和网络故障。通过设计,即使一个节点出现故障,通过提供多个服务器的一个逻辑集群视图,集群也可以“看起来”正常工作。但是,这不能保证客户的活力。因此,etcd客户端已实施了一组不同的复杂协议,以确保其在故障情况下的正确性和高可用性。

从历史上看,etcd客户端平衡器严重依赖于旧的gRPC接口:每次gRPC依赖项升级都会破坏客户端行为。大多数开发和调试工作都致力于解决这些客户端行为更改。结果,由于对服务器连接性的错误假设,其实现变得过于复杂。主要目标是 简化etcd v3.4客户端中的均衡器故障转移逻辑;无需维护可能会过时的不健康终结点列表,而只要客户端与当前终结点断开连接,只需循环到下一个终结点即可。它不具有端点状态。因此,不需要更复杂的状态跟踪。

此外,新客户现在可以创建自己的凭证捆绑包 针对安全端点修复平衡器故障转移 。 这解决了 一年的错误 ,当第一个etcd服务器不可用时,kube-apiserver将失去与etcd集群的连接。

请参阅 客户平衡器设计文档 更多。