1. 程式人生 > >獨家解讀 etcd 3.4版本 |雲原生生態週報 Vol. 18

獨家解讀 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

開源專案推薦

 專案

一個基於 web 的輕量級、可擴充套件的平臺,幫助開發者理解複雜的 Kubernetes 叢集。
這個 web 平臺主要是作為一個工具,給開發者展示一個應用在 Kubernetes 叢集中的部署和執行,目前支援的比如資源展示、用於 debug 的埠轉發、日誌流、多叢集管理等等。

 專案

一個命令列工具,幫助使用者管理大規模應用部署下的資源。

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