雲原生生態週報 Vol. 2

摘要： Cloud Native Weekly China Vol. 2

業界要聞

1. Kubernetes External Secrets 近日，世界上最大的域名託管公司 Godaddy公司，正式宣佈並詳細解讀了其開源的K8s外部 Secrets 管理項目：Kubernetes External Secrets，簡稱KES。這個項目定義了ExternalSecrets API，讓開發者能夠在K8s內部以和使用內部Secret類似的方式使用外部系統提供的Secrets，大大簡化了開發者爲了讓應用獲取外部Secrets所須要的工做量。從安全的角度，這個方案下降了使用外部Secret時候的攻擊面（外部Secret是經過一個K8s API暴露的，而不是以前的每一個應用本身實現），也下降了應用在適配外部Secret時候的難度。另外，Kubernetes KMS plugin開源插件 ，採用信封加密的方式與密鑰管理能力結合，對進行K8s secret的存儲加密。建議安全相關技術人員重點關注。
2. CNCF 官方宣佈爲中國開發者提供免費的雲原生技術公開課。這些課程將專一於雲原生技術堆棧，包括技術深度探索與動手實驗課程，旨在幫助和指導中國開發人員在生產環境中使用雲原生技術，並瞭解其用例和優點。此前，著名社區Stackoverflow發佈了2019年開發者調研報告，報告有近九萬人參與，Top 3 最受熱愛開發平臺是分別是Linux（83.1%）、Docker（77.8%）和Kubernetes（76.8%）。

上游重要進展

Kubernetes 項目

1. [重要性能優化] 2X performance improvement on both required and preferred PodAffinity. (#76243, @Huang-Wei) 這是一個重要的性能優化。這個提交將 PodAffinity 調度的效率實現了兩倍的提升。要知道，PodAffinity/Anti-affinity 調度規則是目前 K8s 默認調度器最大的性能瓶頸點，此次修復很值得關注。
2. [重要安全加強] KEP: Node-Scoped DaemonSet: K8s 項目如今提供一種叫 Node-Scoped DaemonSet。這種 DaemonSet 的獨特之處，在於它擁有、而且只能擁有本身所在的節點 kubelet 相同的權限，而且遵循同 kubelet 相同的鑑權流程。這種設計，避免了以往 DaemonSet 權限氾濫的問題（好比：咱們如今就可讓 DaemonSet 只能訪問到屬於該 Node 的 API 資源）。這個特性發布後， DaemonSet 一直以來都 是K8s 集羣裏最優先被黑客們關照的尷尬局面有望從根本上獲得緩解。
3. [重要功能補丁] KEP: Add kubelet support lxcfs: 一直以來，容器裏面經過 /proc 文件系統查看 CPU、內存等信息不許確都是一個讓人頭疼的問題，而掛載 lxcfs 則是這個問題的最多見解決辦法。如今， K8s 上游正在提議將 lxcfs 做爲默認支持，若是得以合併的話，那對於開發者和運維人員來講，都是個喜聞樂見的事情。不過，lxcfs 自己是一個須要額外安裝的軟件，極可能會成爲這個阻礙設計的 blocker。

Knative 項目

1. [Serving v1beta1 API proposal(https://docs.google.com/presentation/d/10wuLMFXyol731WKuO5x7lalWrH0A6YVHa4exIERQaQ8/edit#slide=id.p)Knative) serving API準備升級到 v1beta1 版本，其目標之一是使用標準的PodSpec，以便更方便的從 K8s Deployment 遷移過來。 這個版本和v1alpha1對比主要變動有：去掉了runLatest，缺省默認就是runLatest；Release模式能夠經過配置traffic實現，能夠指定各個版本的流量比例；取消Manual模式；提供revision生成名字的控制；停用Serving內置的Build。
2. Triggers don't use Istio VirtualServices：Knative Eventing 原有的實現，依賴於 Istio 的 VirtualService 來重寫 Host Header，使得接下來 Broker 能夠經過 Host Header 來識別此 Event 是發給哪一個Trigger 的。而最新的作法，則是經過 URL 來進行區分（好比： http://foo-broker-filter-1da3a.default.svc.cluster.local/my-trigger 表明此事件是發送給 my-trigger 的)，從而解除了 Trigger 對Istio VirtualService 的依賴
3. Remove Istio as a dependency：除了上述解耦以外，Knative Eventing Channel 和 Bus 的綁定目前也是經過 istio 的 VirtualService 實現的。在這個新的實現方案中，Provisioners 直接把 Bus 的 主機名寫到 channel 的狀態當中，就再也不須要 Istio VirtualService 來充當 Proxy 了。這些提交，都在透出這樣一個事實：Knative 正在逐步減小對 Istio 的各類依賴，這對於一個真正、適用於更普遍場景的 Serverless 基礎設施來講，是很是重要的。

Istio 項目

1. [重要安全加強]最近在Envoy代理中發現了兩個安全漏洞（CVE 2019-9900和CVE 2019-9901）。這些漏洞如今已經在Envoy版本1.9.1中修補，而且相應地嵌入在Istio 1.1.2和Istio 1.0.7中的Envoy版本中。因爲Envoy是Istio不可分割的一部分，所以建議用戶當即更新Istio以下降這些漏洞帶來的安全風險。
2. [性能提高] Istio 1.1中的新加強功能能夠提升應用程序性能和服務管理效率，從而實現擴展，Pilot CPU使用率下降了90％, 內存使用率下降50％。業界已有嘗試在Kubernetes中使用Pilot實現服務的流量管理，對應用服務提供多版本管理、靈活的流量治理策略，以支持多種灰度發佈場景。能夠參考經過Istio管理應用的灰度發佈

containerd 項目

1. runc v2 shim 支持 cgroup 設置：containerd 目前支持多個容器使用同一個containerd-shim 來管理 - 一個 Pod 就可使用一個 containerd-shim 來管理一組容器，減小 containerd-shim 對系統資源的開銷。可是目前新的 shim v2 沒有提供配置 Cgroup 接口，這個功能會在 1.3 Release 中解決。有了這個能力以後，上層應用就能夠將 containerd-shim 資源控制也歸入 Pod 資源管理體系中，嚴格控制系統服務佔用的資源大小。
2. containerd 插件 ID 管理：containerd 容許開發者將自定義的組件註冊到服務裏，提供了可插拔的能力。可是當前 containerd 插件的管理是假設 ID 是惟一，這會致使相同 ID 的插件加載結果不可預測。當前該問題還在討論中，計劃在 1.3 Release 中解決。

本週雲原生最佳實踐

傳統富容器運維模式如何雲原生化？

1. 在不少企業當中長期以來都在使用富容器模式，即：在業務容器裏安裝systemd、 sshd、監控進程等系統進程，模擬一個虛擬機的行爲。這種運維方式當然方便業務遷入，可是也跟雲原生理念中的「不可變基礎設施」產生了本質衝突。好比：容器裏的內容被操做人員頻繁變化給升級、發佈帶來了衆多運維隱患；富容器模式致使開發人員其實並不瞭解容器概念，在容器裏隨機位置寫日誌甚至用戶數據等高風險的行爲家常便飯。

2. 來自阿里巴巴「全站雲化」的實踐：

• 將富容器容器運行時替換爲支持 CRI 體系的標準容器運行時好比 containerd 等。目前阿里已經將 PouchContainer 全面升級爲 containerd 發行版。
• 把富容器裏面的耦合在一塊兒進程、服務進行拆分，變成一個 Pod 裏的多個容器，下面是「全站雲化」採用的拆分方法： (1) 業務容器：運行業務主進程，容許 exec 方式進入；(2) 運維 Sidecar 容器：日誌收集、debugger、運維輔助進程等 ；(3) 業務輔助容器：Service Mesh 的 agent

開源項目推薦

1. 本週咱們想您推薦SPIFFE項目。SPIFFE，從運維人員的第一感受而言，是解決證書下發問題的。以往的安全體系更注重天然人的身份認證，而在SPIFFE裏面全部的運行實體都有身份。一個案例就是K8s上的每一個pod都配置相應的身份，對於多雲和混合雲的安全角度講，SPIFFE的好處在於不被供應商的安全認證體系綁定，能夠達到跨雲/跨域的身份認證，從而確保安全。下面是咱們蒐集的一些關於SPIFFE的不錯的公開資料，有興趣能夠去了解：

   • 項目的主要發起人Evan的演講
   • SPIRE是SPIFFE的實現，和Service Mesh結合詳見這篇文章
   • SPIRE的零信任安全機制

本週閱讀推薦

1. Knative：精簡代碼之道，做者 Brian McClain | 譯者 孫海洲。這篇文章用按部就班的例子對「什麼是 Knative」作出了很好的回答。若是你如今對 Knative 的認識還停留在三張分別叫作Build， Serving 和 Eventing的插圖的話，那可能閱讀一下這篇文章會讓你對它們的理解更加形象。
2. Spark in action on Kubernetes - 存儲篇，by Alibaba 莫源。存儲永遠是大數據計算的核心之一，隨着新計算場景的不斷涌現和硬件技術的飛速發展，存儲的適配關係到大規模計算的成本、性能、穩定性等核心競爭要素。本文繼上面分析K8s中的Spark Operator以後，從硬件限制、計算成本和存儲成本幾個角度，討論了雲原生時代來臨後存儲如何解決成本低、存得多、讀寫快這幾個挑戰，詳細介紹了阿里雲上相關產品在不一樣場景下的表現，並總結了不一樣場景下適用的存儲解決方案以及選擇的緣由。若是你是K8s和大數據方面的開發者和使用者，這是一篇你不該該錯過的博客，能夠快速的幫你梳理當前技術下存儲的場景和典型解決方案。

本週報由阿里巴巴容器平臺聯合螞蟻金服共同發佈

本週做者：傅偉，敖小劍，張磊，臨石，南異，心貴，王夕寧，長慮

責任編輯：木環

 

---

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。