獨家解讀 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/<br />從報告提供的各種圖表中，能夠直觀感覺到 Kubernetes 從 2014 年到今天這 5 年來的變化，以及當前 Kubernetes 在雲原生領域和全球的巨大影響力。

上游重要進展

Kubernetes

1.KEP：把 scheduler 中的 priorities、predicates 函數設置爲 deprecated

https://github.com/kubernetes/enhancements/pull/1230<br />由於 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<br />按照 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<br />這個 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 的同窗閱讀。