雲原生生態週報 Vol. 3 | Java 8 ❤️ Docker

業界要聞
Docker Hub遭入侵，19萬帳號被泄露 : 4月25日Docker官方郵件曝露，由於Hub的一個數據庫收到非受權訪問，影響了約19萬用戶的用戶名和哈希後的密碼，以及用戶自動構建的Github和Bitbucket Token。Docker公司建議用戶修改其登陸密碼。若是您在公有云上的應用依賴於來自 Docker Hub的鏡像，咱們強烈建議您登陸容器服務控制檯更新相應的docker login信息或kubernetes secret。此外，阿里雲容器鏡像服務企業版提供網絡訪問控制、獨享OSS Bucket加密存儲等安全加固功能，最大程度保障您的鏡像倉庫的安全。
Java 8 終於開始提供良好的容器支持：長久以來，容器 和 Java 就像一對「歡喜冤家」。一方面，容器技術的「不可變基礎設施」特性爲開發者帶來了無比寶貴的依賴與環境一致性保證；但另外一方面， Linux 容器經過 Cgroups 對應用進行資源限制的方式跟全部依賴於 JVM 進行資源分配的編程語言都產生了本質的衝突。而就在上週，最近發佈的OpenJDK 鏡像 openjdk:8u212-jdk 終於可以讓 Java 8 運行時在容器裏面爲應用分配出合理的 CPU 數目和堆棧大小了。自此，發佈 Java 容器應用的痛苦經歷，可能要一去不復返了。
Snyk 年度安全報告出爐，容器安全問題形勢空前嚴峻：知名開源安全廠商 Snyk 在年初發布了 2019 年度安全報告。報告中指出：「隨着容器技術在2019年繼續在IT環境中爆發式增加，針對容器安全的威脅正在迅猛增長，任何一家企業如今都必須比以往更加劇視容器鏡像安全，並將此做爲企業的首要任務」。報告詳情，請點擊此處查看全文。
上游重要進展
Kubernetes 項目

Kubernetes 集羣聯邦 v1（Federation v1） 正式宣佈廢棄。K8s 社區近日宣佈將 Federation v1 代碼庫正式廢棄。Federation v1 即 Kubernetes 項目原「集羣聯邦」特性，旨在經過一個統一的入口管理多個 Kubernetes 集羣。可是，這個特性逐步被設計成了在多個 Kubernetes 集羣之上構建一個 「Federation 層」的方式來實現，從而背離了 Kubernetes 項目的設計初衷。最終，在 RedHat、CoreOS、Google 等多位社區成員的推進下，社區開始全面擁抱 Federation v2：一個徹底旁路控制、以 K8s API 爲核心的多集羣管理方案。
Kubernetes 1.15 進入發佈節奏 K8s 1.15 發佈進入日程，5 月30 日即將 Code Freeze（即：不接受任何功能性 PR）。
[KEP] Ephemeral Containers KEP 合併，進入編碼階段。
Ephemeral container 旨在經過在 Pod 裏啓動一個臨時容器的方式，來爲用戶提供對Pod和容器應用進行debug和trouble shooting的能力。這種經過「容器設計模式」而非 SSH 等傳統手段解決運維難題的思路，對於「不可變基礎設施」的重要性不言而喻，阿里巴巴在「全站雲化」過程當中也採用了一樣的設計來解決相似問題。在上游完成該功能的編碼實現後，會經過 kubectl debug 命令方便用戶直接使用。
Knative 項目

Knative 逐步棄用原 Build 項目。按照計劃，Tektoncd/Pipeline 子項目已經在 v0.2.0 時移除了對 Build 的依賴。最近，Knative Serving v1beta1 也移除了對 Build 的依賴，目前，社區已經開始制定棄用 Build 的確切方式並通知到 knative 開發者社區。
knative 正在考慮爲事件觸發（Trigger）引入更高級的規則和策略。 社區正在就 Advanced Filtering 設計一個 提案。該提案提議基於 CEL （Google 維護的一種表達式語言）來進行事件的過濾。具體來講，Trigger 的 filter 字段會增長一個 Spec 字段，而後在 Spec 字段下使用 CEL 語法完成對事件的過濾規則定義。
Istio/Envoy 項目

Istio 1.1.4本週正式發佈，其中一個重要的功能是更改了Pilot的默認行爲，對出口流量的控制變化。除了以前經過Service Entry與配置特定範圍IP段來支持訪問外部服務，新版本中經過設置環境變量PILOT_ENABLE_FALLTHROUGH_ROUTE容許Envoy代理將請求傳遞給未在網格內部配置的服務。更多能夠參考Istio流量管理實踐系列文章。
Envoy正經過ORCA改善負載均衡的精準度。
目前Envoy能夠用於進行負載均衡決策的信息主要是權重和鏈接數等信息，爲了能讓Envoy的負載均衡更加精準須要爲Envoy提供更多的決策因素。好比本地和遠程機器的負載狀況、CPU、內存等信息，更復雜的還能夠利用應用程序特定的指標信息來進行決策，好比隊列長度。而ORCA的目的是定義Envoy和上游代理之間傳遞這些信息的標準。該功能的提出者但願ORCA能夠成爲Universal Data Plane API (UDPA)。
Envoy正引入RPC去代替共享內存機制以便提升統計模塊的的擴展性。
Envoy當下經過共享內存的方式來保存stats數據的這種方式存在不少侷限性，好比須要限制stats使用固定的內存大小，當有大量集羣的時候沒辦法擴展。這給他升級stats子系統的架構帶來了很多的阻礙。所以他但願能夠經過將stats數據以堆內存的方式來保存，而後經過RPC在新老進程中傳遞。
Envoy正在xDS協議中增長VHDS協議減少動態路由信息的更新粒度。
現狀是，Envoy中的路由配置是經過RDS來動態更新的，可是RDS的粒度太粗了，包含了一個Listener下全部的路由配置信息。因爲一個Listener下面可能會有多個服務，每個服務對應一個Virtual Host，所以在更新路由的時候，若是隻是其中一個Virtual Host更新了，那麼會致使全部的路由配置都從新下發而致使通信負荷偏重。引入VHDS就是爲了只下發變化的路由信息，從而將更新的路由配置信息量縮小。
Containerd 項目

Non-root用戶運行 containerd： 近日，社區正在嘗試實現無需root權限就能夠運行containerd的能力。在這種場景下，用戶能夠提早準備好容器所須要的 rootfs ，可是 containerd 服務端在清理容器時依然會嘗試去 unmount rootfs，對於沒有 root 權限的 containerd 進程而言，該步驟一定會失敗（mount 操做必需要有 root 權限）。目前 Pivotal 的工程師正在解決這個問題，這種 non-root 模式能夠爲解決雲上安全問題提供新的思路，
開源項目推薦
本週，咱們向您推薦 kubeCDN 項目。
kubeCDN 項目是一個基於Kubernetes 實現的自託管 CDN 方案，只要將它部署在分佈在不一樣地域（Region） 的 Kubernetes 集羣上，你就擁有了一個跨地域進行內容分發的 CDN 網絡。而更重要的是，經過 kubeCDN，用戶再也不須要第三方的內容分發網絡，從而從新控制了本來就屬於本身的從服務器到用戶設備的數據流。kubeCDN 目前只是一個我的項目，可是這裏體現出來的思想確實相當重要的：在不久的將來，每一朵雲、每個數據中內心都會佈滿 Kubernetes 項目，這將會成爲將來雲時代基礎設施的「第一假設」。 推薦你閱讀 InfoQ 的解讀文章來進一步瞭解 kubeCND。
本週閱讀推薦
《Knative 入門——構建基於Kubernetes的現代化Serviceless應用》中文版，這是一本O’Reilly 出品的免費電子書，已經由 servicemesher 社區組織完成翻譯。提供 在線閱讀 和 PDF下載
信通院發起的雲原生產業聯盟出具《雲原生技術實踐白皮書》，白皮書系統性地梳理了雲原生概念、關鍵技術、應用場景、發展趨勢及實踐案例。PDF連接
《阿里雲 PB 級 Kubernetes 日誌平臺建設實踐》Kubernetes 近兩年來發展十分迅速，已經成爲容器編排領域的事實標準，可是 Kubernetes 中日誌採集相對困難。本文來自InfoQ記者的採訪，文中談及瞭如何讓使用者專一在「分析」上，遠離瑣碎的工做。
《Istio Observability with Go, gRPC, and Protocol Buffers-based Microservices》，這是一篇很長的博文，介紹能夠與Istio相適配的觀測性組件，用實際的例子演示瞭如何對以Go語言、Protobuf和gRPC爲基礎的微服務框架進行全面的觀測。若是你還對Prometheus、Grafana、Jaeger和Kiali這幾個組件感到既熟悉又陌生，而且好奇如何把它們組合在一塊兒使用來提高微服務的可觀測性，這個博客的內容應該會對你頗有幫助。
《雲原生的新思考：爲何說容器已經無處不在了？》這篇文章在對雲原生技術總結的同時，對將來應用趨勢走向進行了展望。「雲原生不但能夠很好的支持互聯網應用，也在深入影響着新的計算架構、新的智能數據應用。以容器、服務網格、微服務、Serverless 爲表明的雲原生技術，帶來一種全新的方式來構建應用。」
名詞解釋：KEP - Kubernetes Enhancement Proposal， 即 Kubernetes 上游設計文檔