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

關注“阿里巴巴云原生”公眾號，回復關鍵詞 “資料” ，即可獲得 2019 全年 meetup 活動 PPT 合集及 K8s 最全知識圖譜。

業(yè)界要聞

etcd 發(fā)布 3.4 版本

etcd 發(fā)布了 3.4 版本，是最近性能提升最大的一次發(fā)布，相信各位已經期待已久了！這次升級帶來穩(wěn)定性和性能等方面諸多優(yōu)化，例如底層存儲優(yōu)化，客戶端優(yōu)化等多個方面。

「阿里巴巴云原生」公眾號將在下周帶來更詳細的解讀分析。

• 阿里聯(lián)合谷歌共同研發(fā)，raft learner 新特性

使用過 zookeeper 的人一定聽說過 observer，etcd 中新的 raft learner 類似于 observer, 它不參與 raft 投票選舉。通過這個新的角色的引入，降低了加入新節(jié)點時給老集群的額外壓力，增加了集群的穩(wěn)定性。除此之外還可以使用它作為集群的熱備或服務一些讀請求。

這一新 feature 是由阿里巴巴工程師和谷歌工程師共同研發(fā)的，未來我們將帶來更詳細的解讀分析，敬請期待。

• 更好的底層存儲實現(xiàn)

本次 etcd 存儲升級針對大規(guī)模的集群有重點優(yōu)化，分為兩方面：

• key/value 存儲層，通過將底層讀事務優(yōu)化為全并發(fā)，大幅度提升了 etcd 讀寫性能。經 Kuberentes?5000節(jié)點性能測試，表明在大規(guī)模讀壓力下，P99 寫的延時降低 97.4%；
• lease 存儲優(yōu)化，通過優(yōu)化 lease 底層存儲實現(xiàn)和算法更新，將查詢，過期失效等 lease 操作時間復雜度降低。并且新的?lease checkpoint 機制確保了 etcd 集群切換 leader 后 lease ttl 的準確。
  • 優(yōu)化的 raft 投票選 leader 機制

etcd 中用 raft 規(guī)定了日志復制和選主的機制。舊有的機制在選主過程中存在隱患，當網絡分區(qū)或新加入節(jié)點不穩(wěn)定時會出現(xiàn)，導致整個集群不穩(wěn)定。新的?pre-vote 機制解決這一問題，提升了集群的穩(wěn)定性。

• 新的客戶端負載均衡

etcd 設計上可以容忍網絡分區(qū)和服務層的部分失效，但是之前的機制依賴舊的 grpc, 這次更新基于新的 gprc版本重新優(yōu)化了客戶端負載均衡，使負載真正均衡，并且解決了之前?failover 失敗問題。

阿里巴巴已對這一更新進行了測試，效果良好。此次更新已合入 Kubernetets master, 預計在 Kubernetes 1.16x 版本發(fā)布。

Kubebuilder v2.0 正式版發(fā)布

對應 controller-runtime v0.2.0 版本，新版的文檔說明：https://book.kubebuilder.io?。新舊版本有以下區(qū)別：

生成的代碼框架調整，目錄結構更加扁平化；

controller-runtime 提供的 DelegatingClient 支持 patch 接口（v1.x 時吐槽很多），webhook 不再支持自動生成 cert 證書，目前官方是推薦用戶部署?cert-manager?配合使用；

簡化為自定義資源編寫 defaults 和 validation 的方法。

5 年了，第一篇 Kubernetes 項目歷程報告發(fā)布

?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 都已經實現(xiàn)，并將會在 1.17 中變?yōu)?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 實現(xiàn)版本里支持。但社區(qū)希望推的是統(tǒng)一接口，盡量抹平不同實現(xiàn)版本的差異性，所以這個 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

增加 kube-apiserver 到 aggregated apiserver 的 discovery 接口超時；https://github.com/kubernetes/kubernetes/pull/82204

解決因為 klog 的問題導致 CoreDNS crash；?https://github.com/kubernetes/kubernetes/pull/82128

kube-apiserver 調用 webhook 升級為 http/1.1。?https://github.com/kubernetes/kubernetes/pull/82090

開源項目推薦

?項目

一個基于 web 的輕量級、可擴展的平臺，幫助開發(fā)者理解復雜的 Kubernetes 集群。
這個 web 平臺主要是作為一個工具，給開發(fā)者展示一個應用在 Kubernetes 集群中的部署和運行，目前支持的比如資源展示、用于 debug 的端口轉發(fā)、日志流、多集群管理等等。

?項目

一個命令行工具，幫助用戶管理大規(guī)模應用部署下的資源。

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 的同學閱讀。

總結

以上是生活随笔為你收集整理的独家解读 etcd 3.4版本 |云原生生态周报 Vol. 18的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。