雲原生生态周報 Vol. 9 | K8s 1.15 後的性能提升

業界要聞

Helm這款包管理工具，作為業界Kubernetes上應用分發的事實标準，其 v3.0.0-alpha.1正式釋出，這是Helm 3的第一個Alpha版本。（ https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 ），标志着 Tiller 這個 Server 端元件正式從 Helm 體系中謝幕
Talos釋出。Talos是一款專門用于部署Kubernetes的作業系統。相對于CoreOS，RancherOS或者LinuxKit這些容器作業系統，Talos更為精簡。但是由于去除了ssh等基礎工具，這對于Ansible等基于ssh的Kubernetes部署工具影響巨大。( https://github.com/talos-systems/talos)
Google推出深度學習容器，這是一種用于部署和測試利用機器學習應用與服務的優化環境。Beta 版本的深度學習容器可在雲與本地工作，進而使得在本地或雲中進行開發或原型設計成為可能。此外，該容器還能直接通路 CUDA、cuDNN、NCCL工具，支援 PyTorch、TensorFlow 2.0 和 TensorFlow 1.13架構。（ https://cloud.google.com/blog/products/ai-machine-learning/introducing-deep-learning-containers-consistent-and-portable-environments ）

Kubernetes 項目性能提升

大規模場景下一定要 Cherry Pick 的幾個特性：
- 優化 Watch event 的 dispatch https://github.com/kubernetes/kubernetes/issues/73958
- NodeLease 功能: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md
client-go 會把 List/Watch 逾時設定為 [5min， 10min)，即在逾時時間後會重新發起 List/Watch，建議 Daemenset 調整這個時間到幾十分鐘甚至數小時級别，不然 Apiserver 可能會因為大量通路崩潰。同時，也在考慮 kubelet 是否也要修改這個值，代碼的注釋裡寫着 5min 是為了平衡負載均衡以及解除負載均衡裝置 watch 的hang住 bug。
client-go RateLimiter 加入 Wait 方法，避免在異步場景下使用 client-go 引起 goruntine 積壓： https://github.com/kubernetes/kubernetes/pull/79375
Webhook 和 Adimission 支援 context-aware，在這個修複之前，Webhook 和 Admission 的性能也可能引起 Apiserver goruntine 積壓進而影響 Apiserver 性能： https://github.com/kubernetes/kubernetes/pull/79376
Kube-Apiserver 到達 IO 瓶頸時，metric 錯誤的将 IO 瓶頸錯誤歸類到 504。我們需要将邏輯處理逾時和寫 IO 逾時分開： https://github.com/kubernetes/kubernetes/pull/79609

Kubernetes 可靠性和穩定性

新引入 WatchBookmark 特性。該特性能大大提高 Kube-Apiserver 的 List/Watch 性能，大家都知道，大規模叢集下各個元件的 List/Watch 會消耗 Kube-Apiserver 巨大的性能開銷，有了該特性，我們可以展望未來的叢集規模又可以上升一個台階。 ( #74074 , @wojtek-t )
Admission 預設開啟 StorageObjectInUseProtection。StorageObjectInUseProtection 能保護正在使用的 PV/PVC 被誤删除。這對手速太快的開發和 SRE 同學是一個很大的福音。( #74610 @oomichi
螞蟻金服在大規模實踐中，發現 Daemonset 有各種釋出和部署 Pod 被卡住的問題，螞蟻同學對 Daemonset Controller 可能發生的一系列死鎖問題做了修複。

參考：

Knative 項目

knative-eventing 0.7.0 釋出，主要特性是：重構channel，為每個 Channel 單獨建立了CRD資源；支援事件順序處理（Sequence）；在 Channel, Subscription, Broker, 以及 Trigger 中增強注釋資訊；事件追蹤支援；事件源增強。詳細說明請見 knative-eventing 0.7.0解讀文章
knative-serving 0.7.0 釋出，主要特性是：釋出 serving.knative.dev/v1beta1 api ；HPA支援根據并發請求名額擴縮容；切換到非root使用者容器；詳細說明請見 knative serving 0.7.0 版本變更。
讨論serving是否支援異步請求：要求請求後馬上傳回，另外可以根據id查詢狀态，目前還沒有結論。從這個需求讨論可以看出serving在擴大自己的場景，不滿足隻做ping-pong式的處理。支援異步請求可以用在以下的場景

Long-running jobs
- - Notifications (e.g. mobile push notification, SMS notification, mass emails, etc)
  - Database migrations
- Batch processing (e.g. data transformation)
- Stream processing
- Highly parallel jobs (document, image, … processing)
- Fan-out workloads
- Serveless Operator

期望在縮容的時候，由autoscaler來決定删除哪些pod 。例如在scale-down時，各個pod的負載不平衡，這個時候希望能挑選sale-down代價最小的pod。serving-revision使用K8-deployment，如果不更換實作方式，需要k8底層支援， k8也有相關的讨論

《 Cloud 2.0：代碼不再為王，Serverless 當道！》這一篇不錯的“務虛”文檔，可以從技術演進的視角去思考雲時代的技術演進。
《微服務架構之「監控系統」》，這篇文檔詳細且完整的描述了微服務架構下的監控系統。使用者可以根據此文檔對微服務的解決方案進行入門級的了解。
《Knative 核心概念介紹：Build、Serving和Eventing 三大核心元件》，面對火熱的Serverless項目Knative，這篇文章對Knative的基礎概念進行了精确的概括總結。

本周報由阿裡巴巴容器平台聯合螞蟻金服共同釋出

本周作者：心貴、莫源、元毅、衷源、張磊

責任編輯：塗南、木環

前期周報回顧