雲原生生態周報 Vol. 17 | Helm 3 發布首個 beta 版本
- 2019 年 10 月 3 日
- 筆記
本周作者 | 墨封、衷源、元毅、有濟、心水
業界要聞
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 項目
- apiserver 對 observed requests 進行更細緻的分類, 對 requests 增加優先順序。目前 apiserver 有比較簡單的機制去防止過載,例如用
max-in-flight
去限制 mutating 和 readonly 的請求,但是除了這兩類請求外,還有一些其他類型的請求可以去做不同的限制。這個 KEP 希望把 apiserver 收到的 request 按優先順序等級進行分類,每個 request 分配到它對應的 concurrency pool,這樣不同優先順序的請求就可以做到不同的請求上限限制。作者在 KEP 里列舉了一些目前在 1.16 中觀察到的 requests。 - 為 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 的進行。
- scheduling framework:為 Kubernetes scheduler 設計的插件式的架構,讓調度特性以插件的形式加入 scheduler(將在 1.17 進行 beta)。https://github.com/kubernetes/enhancements/issues/624 (KEP 比較早)。隨著調度特性越來越多,scheduler 的程式碼越來越龐大,維護日益複雜,同時訂製 scheduler 的開銷也比較大。於是社區希望將 scheduler 做成一個 scheduling framework 的架構,讓其他的調度特性以插件形式註冊到 scheduler,對調度器的拓展也更加靈活。
- 其他更新
- 修復 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 項目
- mvcc: 調整默認的 compact batch 為 1000,compact batch interval 為 10ms。compact batch 影響 compact 的速度,過大的 compact batch 會導致 put/range 的性能下降,過小的 compact batch 又 compact 不了太多的 key。在集團內部,我們把這兩個參數設置為可變,不同的集群根據 qps 進行壓測調節到最優參數。
- 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 項目
-
serving 和 eventing 在功能和穩定性相對平穩後,開始進入性能優化階段,開始進行 benchmark,包括:
– deployment benchmark;
– activator + throttler 的開啟 Throttler ;關閉 Throttler;
– eventing 開始制定測試方案,包括收集響應延遲結果和標準的集群跑測試用例。 -
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 上游設計文檔
—
本周報由阿里巴巴容器平台聯合螞蟻金服共同發布
本周作者:墨封,衷源,元毅,有濟,心水
責任編輯:木環