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的儲存加密。建議安全相關技術人員重點關注。
cncf 官方宣布為中國開發者提供免費的雲原生技術公開課。這些課程將專注於雲原生技術堆疊，包括技術深度探索與動手實驗課程，旨在幫助和指導中國開發人員在生產環境中使用雲原生技術，並了解其用例和優勢。此前，著名社群stackoverflow發布了2023年開發者調研報告，報告有近九萬人參與，top 3 最受熱愛開發平台是分別是linux（83.1%）、docker（77.8%）和kubernetes（76.8%）。
kubernetes 專案
[重要效能優化] 2x performance improvement on both required and preferred podaffinity. (#76243, @huang-wei) 這是乙個重要的效能優化。這個提交將 podaffinity 排程的效率實現了兩倍的提高。要知道，podaffinity/anti-affinity 排程規則是目前 k8s 預設排程器最大的效能瓶頸點，這次修復很值得關注。[重要安全增強] kep: node-scoped daemonset: k8s 專案現在提供一種叫 node-scoped daemonset。這種 daemonset 的獨特之處，在於它擁有、並且只能擁有自己所在的節點 kubelet 相同的許可權，並且遵循同 kubelet 相同的鑑權流程。這種設計，避免了以往 daemonset 許可權氾濫的問題（比如：我們現在就可以讓 daemonset 只能訪問到屬於該 node 的 api 資源）。這個特性發布後， daemonset 一直以來都 是k8s 集群裡最優先被黑客們關照的尷尬局面有望從根本上得到緩解。
[重要功能補丁] kep: add kubelet support lxcfs: 一直以來，容器裡面通過 /proc 檔案系統檢視 cpu、記憶體等資訊不準確都是乙個讓人頭疼的問題，而掛載 lxcfs 則是這個問題的最常見解決辦法。現在， k8s 上游正在提議將 lxcfs 作為預設支援，如果得以合併的話，那對於開發者和運維人員來說，都是個喜聞樂見的事情。不過，lxcfs 本身是乙個需要額外安裝的軟體，很可能會成為這個阻礙設計的 blocker。
knative 專案
[serving v1beta1 api proposal(knativeserving api準備公升級到 v1beta1 版本，其目標之一是使用標準的podspec，以便更方便的從 k8s deployment 遷移過來。 這個版本和v1alpha1對比主要變更有：去掉了runlatest，預設預設就是runlatest；release模式可以通過配置traffic實現，可以指定各個版本的流量比例；取消manual模式；提供revision生成名字的控制；停用serving內建的build。
triggers don't use istio virtualservices：knative eventing 原有的實現，依賴於 istio 的 virtualservice 來重寫 host header，使得接下來 broker 可以通過 host header 來識別此 event 是發給哪個trigger 的。而最新的做法，則是通過 url 來進行區分（比如： 代表此事件是傳送給 my-trigger 的)，從而解除了 trigger 對istio virtualservice 的依賴remove istio as a dependency：除了上述解耦之外，knative eventing channel 和 bus 的繫結目前也是通過 istio 的 virtualservice 實現的。在這個新的實現方案中，provisioners 直接把 bus 的 主機名寫到 channel 的狀態當中，就不再需要 istio virtualservice 來充當 proxy 了。這些提交，都在透出這樣乙個事實：knative 正在逐步減少對 istio 的各種依賴，這對於乙個真正、適用於更廣泛場景的 serverless 基礎設施來說，是非常重要的。
istio 專案
[重要安全增強]最近在envoy**中發現了兩個安全漏洞（cve 2019-9900和cve 2019-9901）。這些漏洞現在已經在envoy版本1.9.1中修補，並且相應地嵌入在istio 1.1.2和istio 1.0.7中的envoy版本中。由於envoy是istio不可分割的一部分，因此建議使用者立即更新istio以降低這些漏洞帶來的安全風險。
[效能提公升] istio 1.1中的新增強功能可以提高應用程式效能和服務管理效率，從而實現擴充套件，pilot cpu使用率降低了90％, 記憶體使用率降低50％。業界已有嘗試在kubernetes中使用pilot實現服務的流量管理，對應用服務提供多版本管理、靈活的流量治理策略，以支援多種灰度發布場景。可以參考通過istio管理應用的灰度發布
containerd 專案
runc v2 shim
支援cgroup
設定：containerd 目前支援多個容器使用同乙個
containerd-shim
來管理 - 乙個 pod 就可以使用乙個 containerd-shim 來管理一組容器，減少 containerd-shim 對系統資源的開銷。但是目前新的 shim v2 沒有提供配置 cgroup 介面，這個功能會在 1.3 release 中解決。有了這個能力之後，上層應用就可以將 containerd-shim 資源控制也納入 pod 資源管理體系中，嚴格控制系統服務占用的資源大小。
containerd 外掛程式 id 管理：containerd 允許開發者將自定義的元件註冊到服務裡，提供了可插拔的能力。但是當前 containerd 外掛程式的管理是假設 id 是唯一，這會導致相同 id 的外掛程式載入結果不可**。當前該問題還在討論中，計畫在 1.3 release 中解決。
傳統富容器運維模式如何云原生化？
在很多企業當中長期以來都在使用富容器模式，即：在業務容器裡安裝systemd、 sshd、監控程序等系統程序，模擬乙個虛擬機器的行為。這種運維方式固然方便業務遷入，但是也跟雲原生理念中的「不可變基礎設施」產生了本質衝突。比如：容器裡的內容被操作人員頻繁變化給公升級、發布帶來了眾多運維隱患；富容器模式導致開發人員其實並不了解容器概念，在容器裡隨機位置寫日誌甚至使用者資料等高風險的行為屢見不鮮。
來自阿里巴巴「全站雲化」的實踐：
本週我們想您推薦spiffe專案。spiffe，從運維人員的第一感覺而言，是解決證書下發問題的。以往的安全體系更注重自然人的身份認證，而在spiffe裡面所有的執行實體都有身份。乙個案例就是k8s上的每個pod都配置相應的身份，對於多雲和混合雲的安全角度講，spiffe的好處在於不被**商的安全認證體系繫結，可以達到跨雲/跨域的身份認證，從而確保安全。下面是我們蒐集的一些關於spiffe的不錯的公開資料，有興趣可以去了解：
knative：精簡**之道，作者 brian mcclain | 譯者 孫海洲。這篇文章用循序漸進的例子對「什麼是 knative」做出了很好的回答。如果你現在對 knative 的認識還停留在三張分別叫做build， serving 和 eventing的插圖的話，那可能閱讀一下這篇文章會讓你對它們的理解更加形象。
spark in action on kubernetes - 儲存篇，by alibaba 莫源。儲存永遠是大資料計算的核心之一，隨著新計算場景的不斷湧現和硬體技術的飛速發展，儲存的適配關係到大規模計算的成本、效能、穩定性等核心競爭要素。本文繼上面分析k8s中的spark operator之後，從硬體限制、計算成本和儲存成本幾個角度，討論了雲原生時代來臨後儲存如何解決成本低、存得多、讀寫快這幾個挑戰，詳細介紹了阿里雲上相關產品在不同場景下的表現，並總結了不同場景下適用的儲存解決方案以及選擇的原因。如果你是k8s和大資料方面的開發者和使用者，這是一篇你不應該錯過的部落格，可以快速的幫你梳理當前技術下儲存的場景和典型解決方案。
本週報由阿里巴巴容器平台聯合螞蟻金服共同發布
雲原生 雲原生簡介
進一年我們都在使用雲原生框架 springcloud微服務開發專案，敏捷快速 部署在容器中，解決部署環境差異 使用devops自動部署，減少運維壓力 本質是乙個與宿主機系統共享核心，但與系統中的其他程序資源相隔離的執行環境。docker容器，是當前認可度高 社群和生態最活躍的開源容器技術。devop...
php 原生生成xls和csv
參考文獻 1 生成xls 核心 開始輸出 excel new excel 引入類檔案，例項化類 header content type text html charset utf 8 header pragma public header expires 0 header cache control...
Android原生生成JSON與解析JSON
json資料是一種輕量級的資料交換格式，在 android 中通常應用於客戶端與伺服器互動之間的資料傳輸。像現在在網上有很多解析 json 資料的jar 包，但是歸根到底用的都是 android 原生解析 json 資料的方式，所以掌握 android 原生解析 json 資料的方法相當重要。下面分...