Kubernetes团队发布了Etcd 3.4版本，这个版本强化了储存后端的效率，并改进Raft投票程序，还加入了全新的客户端平衡器（Client Balancer）。Etcd是一个具高可靠性的（Key/Value）键值储存，可用来储存分布式系统的重要资料，在去年底，CoreOS团队将Etcd项目捐赠给CNCF。

 

新版Etcd对大规模Kubernetes工作负载进行了最佳优化，大幅提升了执行效率，其最重要的更新提供更好的存储后端。在之前的版本，即便没有任何写入任务，Etcd也会在大量读取交易的时候出现效率问题，花费过长的时间执行读写工作，而原因在于，储存后端在提交等待写入操作时，会阻挡进来的读取交易，而且即便没有待处理的写入资料，也会发生同样的问题。现在，提交不会阻挡读取工作，而这能改善长时间的读取交易效率。

 

另外，开发团队也让后端读取交易更加并行，这将使得资料吞吐量大增70％，长时间进行读取操作的情况下，P99写入延迟减少了90％。官方也对租约储存（Lease Storage）进行了许多改进，以提高整体操作效率，新版本还新增实验性的租约检查点功能，能通过共识机制，保存租约物件的剩余生存时间值。

 

Etcd使用Raft算法进行资料复制，过去在当一个新的成员加入或是离开集群时，可能会影响整体集群的可用性，而这个情况在网络分区（Network Partition）时更加严重。开发团队在Etcd 3.4改进了Raft投票流程，并加入预投票功能，以解决在网络分区的情况下，可能出现的中断问题。

 

Etcd 3.4的重大更新还包括添加新的客户端平衡器。Etcd被设计成可以容忍各种系统和网络故障，即便其中一个节点发生故障，多服务器架构下的逻辑集群看起来仍然运作正常，但是这种情况却无法保证客户端也能够正确运行，而过去Etcd客户端采用了复杂的协定，以确保在任何错误情况发生时，仍然可以维持正确性与可用性。

 

但由于Etcd客户端平衡器过度依赖旧的gRPC界面，因此当gRPC相依项目升级时，便会破坏客户端的行为，因此开发团队花了许多的心力修复这些问题，但叠床架屋的结果，使得客户端对服务器的连接机制过于复杂。Etcd 3.4客户端简化了平衡器故障转移逻辑，不再维护不健康的端点列表，因为当端点连结中断时，列表就可能过时，现在客户端与当前端点连结中断，便会由下一个端点轮替，客户端也就不用追踪端点状态。另外，新客户端会创建自己的凭证綑绑包，以修正安全端点的故障转移问题，开发团队提到，之前当第一个Etcd服务器故障的时候，kube-apiserver就无法与Etcd集群连结，而Etcd 3.4更新修正了这个存在一年的臭虫。

参考：https://www.ithome.com.tw/news/132821

https://kubernetes.io/blog/2019/08/30/announcing-etcd-3-4/

https://github.com/etcd-io/etcd/blob/master/CHANGELOG-3.4.md