云原生生态周报 Vol. 18：独家解读 etcd 3.4 新特性_服务革新_宇慕

【AICon】探索八个行业创新案例，教你在教育、金融、医疗、法律等领域实践大模型技术！ >>> 了解详情 



 写点什么

前言

《云原生生态周报》由阿里云容器平台联合蚂蚁金服共同发布，每周一期。众多一线社区专家与您一起“跟踪动态，读懂社区”，分享云原生社区项目进展、活动发布、精选博客等信息。以下是第十八期云原生生态周报的内容。

业界要闻

etcd 发布 3.4 版本

etcd 发布了 3.4 版本，是最近性能提升最大的一次发布，相信各位已经期待已久了！这次升级带来稳定性和性能等方面诸多优化，例如底层存储优化、客户端优化等。

阿里联合谷歌共同研发，raft learner 新特性

使用过 zookeeper 的人一定听说过 observer，etcd 中新的 raft learner 类似于 observer, 它不参与 raft 投票选举。通过这个新角色的引入，降低了加入新节点时给老集群的额外压力，增强了集群的稳定性。除此之外还可以使用它作为集群的热备或服务一些读请求。

这一新 feature 是由阿里巴巴工程师和谷歌工程师共同研发的，未来我们将带来更详细的解读分析，敬请期待。

更好的底层存储实现

本次 etcd 存储升级针对大规模的集群有重点优化，分为两方面：

key/value 存储层，通过将底层读事务优化为全并发，大幅度提升了 etcd 读写性能。经 Kuberentes 5000 节点性能测试，表明在大规模读压力下，P99 写的延时降低 97.4%；
lease 存储优化，通过优化 lease 底层存储实现和算法更新，将查询、过期失效等 lease 操作时间复杂度降低。并且新的 lease checkpoint 机制确保了 etcd 集群切换 leader 后 lease ttl 的准确性。

优化的 raft 投票选 leader 机制

etcd 中用 raft 规定了日志复制和选主的机制。旧有的机制在选主过程中存在隐患，当网络分区或新加入节点不稳定时会出现，导致整个集群不稳定。新的 pre-vote 机制解决了这一问题，提升了集群的稳定性。

新的客户端负载均衡

etcd 设计上可以容忍网络分区和服务层的部分失效，但是之前的机制依赖旧的 grpc，这次更新基于新的 gprc 版本重新优化了客户端负载均衡，使负载真正均衡，并且解决了之前 failover 失败问题。

阿里巴巴已对这一更新进行了测试，效果良好。此次更新已合入 Kubernetets master, 预计在 Kubernetes 1.16x 版本发布。

Kubebuilder v2.0 正式版发布

对应 controller-runtime v0.2.0 版本，发布了新版的文档说明。新旧版本有以下区别：

生成的代码框架调整，目录结构更加扁平化；

controller-runtime 提供的 DelegatingClient 支持 patch 接口（v1.x 时吐槽很多），webhook 不再支持自动生成 cert 证书，目前官方是推荐用户部署 cert-manager 配合使用；

简化为自定义资源编写 defaults 和 validation 的方法。

5 年了，第一篇 Kubernetes 项目历程报告发布

从报告提供的各类图表中，可以直观感受到 Kubernetes 从 2014 年到今天这 5 年来的变化，以及当前 Kubernetes 在云原生领域和全球的巨大影响力。

上游重要进展

Kubernetes

1.KEP：把 scheduler 中的 priorities、predicates 函数设置为 deprecated

因为 scheduling framework 的所有 extension points 都已经实现，并将会在 1.17 中变为 beta 版本，希望将当前 scheduler 中的 priorities、predicates 函数开始设置为 deprecated，并将它们改为 scheduling framework 的插件。

2.KEP：允许 exec 命令使用 -u 参数指定 username

按照 KEP 作者的说法，exec 指定 username 便于用户进入容器 debug。但问题在于，CRI 标准接口里是不支持 user 这个 exec 参数的，只是 Docker、Kata、gVisior 这些大多数的 container runtime 实现版本里支持。但社区希望推的是统一接口，尽量抹平不同实现版本的差异性，所以这个 KEP 能否被接受还得打个问号。

3.PR：HPA 中新增 scaling constraints

这个 PR 用于给 HPA 添加 scale down/up 的限制。在 API 层面的改动是在 HorizontalPodAutoscalerSpec 结构中新增了一个 Constraints，HPAScaleConstraints 中定义了 ScaleUp 和 ScaleDown 的限制，在 HPAScaleConstraintRateValue 中支持 3 种限制方式：Pods 数量、Percent 百分比、PeriodSeconds 周期。