本週作者 | 墨封、衷源、元毅、有濟、心水

業界要聞

1. Helm 3 首個 beta 版本 v3.0.0-beta.1 釋出

該版本的重點是完成最後的修改和重構，以及移植其他 Helm 2 特性。https://github.com/helm/helm/releases

2. cilium 1.6 版本釋出

完成了最後的兩個核心需求，宣佈已經可以 100% 替換 kube-proxy。https://cilium.io/blog/2019/08/20/cilium-16/

cilium 是一個基於 eBPF 實現的可用於提供容器網路連線和負載均衡的元件，不依賴 K-V store，以下是 cilium 的效能測試結果。
               

3. pivotal 開源了 controller - kpack

實現映象構建和更新的資源控制器。https://github.com/pivotal/kpack

上游重要進展

Kubernetes 專案

1. apiserver 對 observed requests 進行更細緻的分類， 對 requests 增加優先順序。目前 apiserver 有比較簡單的機制去防止過載，例如用 max-in-flight 去限制 mutating 和 readonly 的請求，但是除了這兩類請求外，還有一些其他型別的請求可以去做不同的限制。這個 KEP 希望把 apiserver 收到的 request 按優先順序等級進行分類，每個 request 分配到它對應的 concurrency pool，這樣不同優先順序的請求就可以做到不同的請求上限限制。作者在 KEP 裡列舉了一些目前在 1.16 中觀察到的 requests。
2. 為 HA master 增加 StorageVersion API。HA master 在 roling upgrade 時，每一個 apiserver 可能會用不同的 storage version 去 encode resource。如果叢集中有 storage version migrator，則會錯誤導致 storage migrator 升級 resource storage version 到不同的版本。增加了一個 StorageVersion API 在這種場景下會告訴 migrator，當前 HA 叢集對 storage version 未達成一致，migrator 會阻塞 migrate 的進行。
3. scheduling framework：為 Kubernetes scheduler 設計的外掛式的架構，讓排程特性以外掛的形式加入 scheduler（將在 1.17 進行 beta）。https://github.com/kubernetes/enhancements/issues/624 （KEP 比較早）。隨著排程特性越來越多，scheduler 的程式碼越來越龐大，維護日益複雜，同時定製 scheduler 的開銷也比較大。於是社群希望將 scheduler 做成一個 scheduling framework 的架構，讓其他的排程特性以外掛形式註冊到 scheduler，對排程器的拓展也更加靈活。

1. 其他更新

• 修復 kubectl -f 在 windows 下不起作用的問題（顯式 follow symlink）。
• Kubernetes API change 相關：CustomResourceDefaulting 被從 featuregate.Alpha 升級到 featuregate.Beta，並預設開啟。v1beta1 webhooks/CRD types 被 deprecated。release 1.13、1.14、1.15中go 版本均升級（解決之前提到的 net/http 安全漏洞影響）
• 允許 apiserver 只以 http1 啟動（DisableHTTP2)，方便某些特殊測試或者生產場景需求。
• scale client 支援非 namespace 的資源（例如 cluster 範圍的 CRD）
• kubelet 計算 pod 使用資源時支援 pod-overhead的場景（evict 時用作參考）

etcd 專案

1. mvcc: 調整預設的 compact batch 為 1000，compact batch interval 為 10ms。compact batch 影響 compact 的速度，過大的 compact batch 會導致 put/range 的效能下降，過小的 compact batch 又 compact 不了太多的 key。在集團內部，我們把這兩個引數設定為可變，不同的叢集根據 qps 進行壓測調節到最優引數。
2. raft：允許 learner 在特殊情況下進行投票。存在這樣的場景：叢集 id=1 是 learner，id=2 是 voter，id=3 是 voter，然後通過客戶端將 learner promote 成 voter，因為網路分割槽等原因，訊息還沒傳到 learner，但是此時 id=2 的 voter 掛了，那麼 id=3 voter 則直接獲得了選舉勝利。實際上此時 learner 已經 promote 成 voter 了，還需要 id=1 的 voter 進行投票。該 PR 修復了這個場景，允許 learner 收到投票，當 learner 收到投票時，表明其他 quorum 將自己視為一個 voter 了。

knative 專案

1. serving 和 eventing 在功能和穩定性相對平穩後，開始進入效能優化階段，開始進行 benchmark，包括：
   - deployment benchmark；
   - activator + throttler 的開啟 Throttler ；關閉 Throttler；
   - eventing 開始制定測試方案，包括收集響應延遲結果和標準的叢集跑測試用例。

2. eventing 將 channel 和 subscriptions 轉移到 messaging.knative.dev API Group。表明 Channel 和 Subscription 的概念是訊息的路由而不是事件的轉發，涉及到如何遷移現存業務，改動較大。

開源專案推薦

microk8s

體積小，執行速度快，single-package 的 K8s 版本，適合用於做 K8s 的離線開發，IOT 和邊緣裝置。https://github.com/ubuntu/microk8s

microk8s 緊跟上游 K8s 的 feature，剛剛 release 了 1.16-beta，同時它包含了主流 K8s 生態的其他工具，包括 serverless（knative），service mesh（istio），monitoring（prometheus，grafana），machine learning（kubeflow）。

qlkube

Kubernetes 的 GraphQL API，允許你使用 graphql 與 Kubernetes api 進行互動。https://github.com/qlkube/qlkube?utm_sq=g5n76aa1mt

GraphQL 是 Facebook 2015 年開源的資料查詢規範。對於現在大多數的 RESTful API，都存在以下場景：

• client 需要向 server 發若干個請求才能獲得所需要查詢的內容；
• GraphQL 則希望讓 API 資料間以圖的形式，有關聯和層次結構進行組織；
• qlkube 是利用 Kubernetes 的 openapi/swagger api specification 自動生成的 GranphQL 介面。

kube-fzf

利用 kubectl 和 fzf 搭建的支援模糊搜尋的命令列工具。https://github.com/thecasualcoder/kube-fzf

fzf （fuzzy finder）是一個非常豐富的命令列模糊搜尋器，而 kube-fzf 把兩個命令列工具結合，減少了 Kubernetes 日常運維時敲的大量 kubectl get po xxx -n xxxxx 的命令複雜度。目前支援搜尋 pod，tail pod container，describe pod，exec into a pod，port forward pod。

本週閱讀推薦

1. 《The State of State in Cloud Native Applications》

https://thenewstack.io/the-state-of-state-in-cloud-native-applications/
在雲原生應用中，有狀態應用的狀態處理和發展過程以及未來走向。

2. 《How Kubernetes Could Orchestrate Machine Learning Pipelines》

https://thenewstack.io/how-kubernetes-could-orchestrate-machine-learning-pipelines/
在過去幾年，Apache YARN 和 Mesos 往往是 data science 型別的 job（尤其是 machine learning）首選的資源排程器，而隨著 Kubernetes 在社群的火爆，在 Kubernetes 上允許 big data 或 analytics job 的使用者越來越多。文章介紹瞭如何使用 kubeflow pipeline 進行 ML 訓練，以及 MLOps 的設計。

3. 《Kubernetes Web UIs in 2019》

https://srcco.de/posts/kubernetes-web-uis-in-2019.html
社群有非常多 Kubernetes Web UI 的專案，作者提出他自己對 Kubernetes UI 的期望，並對所有開源專案做了一個總結。

4. 《深度解讀 Helm 3: 猶抱琵琶半遮面》

自去年年初開始放風 Helm v3 將要開始開發，就被一堆人追問到底啥時候發版本。Helm v3 在五月釋出了第一個 alpha 版本，如今釋出了 beta 版本，本文是一篇舊文解讀 Helm v3 aplha，但是絕對是一篇有助於理解 Helm V3的好文章。

5. 《Knative Eventing 之 Choice 介紹》

從 Knative Eventing 0.8 開始，支援根據不同的過濾條件對事件進行選擇處理。通過 Choice 提供了這樣的能力。本文旨在介紹一下 Choice 特性。

6. 《Service Mesh 發展趨勢(續)：棋到中盤路往何方》

繼續探討 ServiceMesh 發展趨勢，以靈魂拷問的方式深度分析 Istio 的重大革新 Mixer v2，Envoy 支援 Web Assembly 的意義所在; 深入介紹 Google Traffic Director 對虛擬機器模式的創新支援方式，以及最近圍繞 SMI 發生的故事。


名詞解釋：KEP - Kubernetes Enhancement Proposal， 即 Kubernetes 上游設計文件

--
本週報由阿里巴巴容器平臺聯合螞蟻金服共同釋出

本週作者：墨封，衷源，元毅，有濟，心水
責任編輯：木環