独家解读 etcd 3.4 版本 |云原生生态周报 Vol. 18

作者 | 酒祝、墨封、宇慕、衷源

关注“阿里巴巴云原生”公众号，回复关键词 “资料” ，即可获得 2019 全年 meetup 活动 PPT 合集及 K8s 最全知识图谱。

业界要闻

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 版本，新版的文档说明：https://book.kubebuilder.io 。新旧版本有以下区别：

1. 生成的代码框架调整，目录结构更加扁平化；
2. controller-runtime 提供的 DelegatingClient 支持 patch 接口（ v1.x 时吐槽很多），webhook 不再支持自动生成 cert 证书，目前官方是推荐用户部署 cert-manager 配合使用；
3. 简化为自定义资源编写 defaults 和 validation 的方法。

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

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

上游重要进展

Kubernetes

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

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

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

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

3.PR：HPA 中新增 scaling constraints

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

4.bugfix

1. 增加 kube-apiserver 到 aggregated apiserver 的 discovery 接口超时；https://github.com/kubernetes/kubernetes/pull/82204
2. 解决因为 klog 的问题导致 CoreDNS crash； https://github.com/kubernetes/kubernetes/pull/82128
3. kube-apiserver 调用 webhook 升级为 http/1.1。 https://github.com/kubernetes/kubernetes/pull/82090

开源项目推荐

octant 项目

一个基于 web 的轻量级、可扩展的平台，帮助开发者理解复杂的 Kubernetes 集群。
这个 web 平台主要是作为一个工具，给开发者展示一个应用在 Kubernetes 集群中的部署和运行，目前支持的比如资源展示、用于 debug 的端口转发、日志流、多集群管理等等。

kapp 项目

一个命令行工具，帮助用户管理大规模应用部署下的资源。

kapp 工具主要功能包括资源 diffing、label 标记、部署和删除管理等。和 Helm 不同的是，kapp 主要关注的是部署流程，而非打包或者 YAML 模板等，同时在一定程度上支持 GitOps 工作流。

本周阅读推荐

1. 《 How  does "kubectl exec" works?》

通过网路请求和源码分析，解析了一次 kubectl exec 请求是如何从客户端经过 kube-apiserver 和 kubelet，最终建立起到容器内的命令通道。

2. 《 Kubernetes Evolution 》

访谈了来自 22 个公司的人员，“你认为 K8s 的未来和最佳机遇是什么？”

3. 《 Kubernetes Concerns 》

访谈了来自 22 个公司的人员，“你对当前 K8s 的使用上有什么担心之处？”

4. 《 How Kubernetes works 》

本文从小白的视角，介绍了 Kubernetes 的集群结构、一些基本的资源概念以及 master/worker 的各类基础组件，适合于没有接触过或刚开始 K8s 的同学阅读。