作者 | 酒祝、墨封、宇慕、衷源
關注“阿里巴巴雲原生”公眾號，回復關鍵詞 “資料” **，即可獲得 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 。新舊版本有以下區別：
- 生成的代碼框架調整，目錄結構更加扁平化；
- controller-runtime 提供的 DelegatingClient 支持 patch 接口（v1.x 時吐槽很多），webhook 不再支持自動生成 cert 證書，目前官方是推薦用戶部署 cert-manager 配合使用；
- 簡化為自定義資源編寫 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
- 增加 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 的輕量級、可擴展的平台，幫助開發者理解復雜的 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 的同學閱讀。