業界要聞

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和大數據方面的開發者和使用者，這是一篇你不應該錯過的博客，可以快速的幫你梳理當前技術下存儲的場景和典型解決方案。

---

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

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

責任編輯：木環