本文首發於：微信公眾號「雲原生實驗室」，公眾號ID：cloud_native_yang。
這是雲原生週報第 3 期，主要分享雲原生社群最新開源專案和相關資訊。
如果你有什麼優秀專案和資訊，歡迎向我投稿，投稿郵箱：yangchuansheng33@gmail.com。如果你想與大牛一起探討雲原生相關技術問題，可以新增我的微信後拉你進入雲原生交流群，我的微訊號是：yangchuansheng572887。
1. 開源專案推薦
diving : 基於 dive 分析 docker 映象，介面化展示了映象每層的變動（增加、修改、刪除等）、使用者層資料大小等資訊。便捷獲取映象資訊和每層映象內容的檔案樹，可以方便地瀏覽映象資訊。對於需要優化映象體積時非常方便。
Wave : Kubernetes 的配置檔案有兩種，一種是 ConfigMap，用來儲存明文；另一種是 Secret，用來儲存密文。這兩種配置檔案應用都比較廣泛，但遺憾的是，目前它們在大多數場景下都不支援熱更新，只有當 ConfigMap 掛載為 Volume 時，才能支援熱更新，其他場景均不支援。Wave 的做法比較機智，它向 API server 訂閱來自指定的 Deployment（通過 annotations 識別） 的事件，一旦某個 Deployment 被執行了任何操作（Create/Read/Update/Delete），它就會通過演算法來計算該 Deployment 中每個掛載的 ConfigMap and Secret 的 hash 值，如果掛載點發生了變化，或者掛載的資料發生了變化，都會改變 hash 值。由於該 hash 值被寫到 Pod Template 的 Annotation 中，所以 hash 更新就會觸發 Deployment 的滾動更新。
kube-eventer : Kubernetes 的核心設計思想是狀態機。在 Kubernetes 中，事件分為兩種，一種是 Warning 事件，表示產生這個事件的狀態轉換是在非預期的狀態之間產生的；另外一種是 Normal 事件，表示期望到達的狀態，和目前達到的狀態是一致的。通過事件的機制，可以豐富 Kuernetes 在監控方面的維度和準確性，彌補其他監控方案的缺欠。kube-eventer 是為了彌補事件監控場景的缺失，支援將 Kubernetes 事件傳送到釘釘機器人、SLS 日誌服務、Kafka 開源訊息佇列、InfluxDB 時序資料庫等等。
Kubernetes 修仙路徑 : 目前雲端計算行業對於 Kubernetes 學習的需求日益增加，但市面上關於 Kubernetes 的資源良莠不齊，存在幾個問題：
- 官方文件缺少明確的"梯度"，資訊錯綜複雜
- 資料較為分散，查詢資訊費時費力
- Kubernetes 發展很快，書籍或者網上教程容易過時
為了給廣大從業者提供一個 Kubernetes 學習路徑，為大家提供一定的指引，才雲科技（Caicloud） 推出了 Kubernetes 打怪升級指南，目標是讓所有人剝繭抽絲般地瞭解 Kubernetes，不僅僅知道怎麼用 Kubernetes，還知道 Kubernetes 各個功能是如何設計的。在學習路徑後期，我們還可以很"自然"的聯想到正確的設計思路。
YugaByte DB : YugaByte DB 是一個高效能、雲原生的分散式 SQL 資料庫。YugaByte DB 具有基於 Google Spanner 的儲存架構和基於 PostgreSQL 的查詢層，旨在為現代應用程式在雲原生基礎架構上提供分散式 SQL 中的體驗（類似 Oracle）。完全開源之後，其工程團隊將帶領 YugaByte DB 比以往更快地向雲原生模式發展。
GetEnvoy Project : 如果你的工作內容涉及到大型分散式系統，那你可能會聽說過 Envoy，它是一款為雲原生應用而設計、開源的邊緣和服務代理，也是 Istio Service Mesh 預設的資料平面。但目前最痛苦的問題是 Envoy 很難編譯，為了解決這個問題，Tetrate 的工程師（包括 Envoy 的核心貢獻者和維護者）發起了 GetEnvoy 專案，目標是利用一套經過驗證的構建工具來構建 Envoy，並通過常用的軟體包管理器來分發，包括：apt、yum 和 Homebrew。下圖是我通過 Homebrew 安裝的 Envoy：
GRBAC : Grbac 是一個快速，優雅和簡潔的 RBAC 框架。它支援增強的萬用字元並使用 Radix 樹匹配 HTTP 請求。令人驚奇的是，您可以在任何現有的資料庫和資料結構中輕鬆使用它。
ccheck : 一個用來驗證 Kubernetes 資源配置的命令列工具。它通過使用 reg 查詢語言來編寫針對 yaml 檔案的測試。
ceph-study : Ceph 是一個可靠、自動均衡、自動恢復的分散式儲存系統，通常可用於物件儲存，塊裝置儲存和檔案系統儲存。 Ceph 在儲存的時候充分利用儲存節點的計算能力，在儲存每一個資料時都會通過計算得出該資料的位置，儘量的分佈均衡。ceph-study 是網友整理的一份 ceph 學習指南，寫的十分詳細，歡迎初學者瀏覽學習。
2. 部落格推薦
到底要不要把資料庫執行在 Kubernetes 中 : 如今越來越多的應用都跑在 Kubernetes 上，Kubernetes 已經成為雲時代的 Linux 作業系統。儘管如此，資料庫的部署方式並沒有因為 Kubernetes 的浪潮而受到太多影響，因為要想容器化，就要考慮資料庫能否自動重啟、橫向擴充套件，能否適應容器隔離技術的限制。本文將會通過合理的邏輯推理告訴你到底要不要把資料庫執行在 Kubernetes。
Kubernetes 中的 Java 應用效能優化 : 在 Kubernetes 中部署應用並沒有想象中那麼簡單，如果配置不恰當，就會遇到頻繁的 oom kills 和 重啟，尤其是 Java 應用需要特別關注。本文以一個 Spring Boot 微服務應用為例，分析應用啟動消耗的 CPU 和記憶體資源，然後告訴我們如何調整資源的 requests 和 limits 來提高應用的啟動速度，並防止因為 OOM 機制被 kill 掉。
K8S 避坑指南 - Deployment 更新 POD 內容器無法收到 SIGTERM 訊號 : 正常情況下，在 Deployment 滾動更新時，當 pod 被 terminate 的時候，應用程式應該能夠正確處理 SIGTERM 訊號。如果應用不能正確處理 SIGTERM 訊號，一般都是因為應用程式不是容器內的 1 號程式，需要調整容器的啟動命令來解決問題。
為容器提供更好的隔離：沙箱容器技術概覽 : Docker、LXC 以及 RKT 等傳統容器都是共享主機作業系統核心的，因此不能稱之為真正的沙箱。這些技術的資源利用率很高，但是受攻擊面積和潛在的攻擊影響都很大，在多租戶的雲環境中，不同客戶的容器會被同樣的進行編排，這種威脅就尤其明顯。主機作業系統在為每個容器建立虛擬的使用者空間時，不同容器之間的隔離是很薄弱的，這是造成上述問題的根本原因。基於這樣的現狀，真正的沙箱式容器，成為很多研發工作的焦點。多數方案都對容器之間的邊界進行了重新架構，以增強隔離。本文覆蓋了四個專案，分別來自於 IBM、Google、Amazon 以及 OpenStack，幾個方案的目標是一致的：為容器提供更強的隔離。如果你想抓住即將到來的轉型機會，不妨關注一下這些新專案。
解決在 Kubernetes 中刪除 namespace 一直處於 terminating 狀態的問題 : 作者在生產環境中刪除某個 namespace 時一直處於 terminating 狀態，最後發現是因為在 namespace 中通過 Finalizers 呼叫了 pre-delete hooks，所以一直卡在那邊。具體的解決辦法請查閱文章。
papers-notebook : 這是一篇論文閱讀筆記，其中的論文一部分來自於在上海交通大學軟體學院的研究生課上需要閱讀的論文，這部分會比較偏安全和虛擬化。還有一部分論文是作者感興趣，想去了解的，這部分可能比較偏虛擬化和分散式。論文筆記希望能夠記錄自己在讀論文的時候的想法，其中包括但不限於論文的大致 idea，實現方式，以及自己對論文的評價等等。
從CNI到OVN : 本文主要介紹了 ovn ovs 怎麼與 kubernetes 擦出火花。全文主要分為兩個部分，第一部分先簡單介紹 CNI 的工作原理，然後開始安裝 OVS 和 OVN，並測試跨主機容器的連通性。第二部分主要介紹 Openflow 和 OVN 的工作原理和相關實踐。
gRPC 服務發現與服務治理技術選型 : gRPC 服務發現與服務治理,目前常見解決方案有以下兩種：
- Nginx + consul + consul-template
- Envoy
本文粗略講解了兩種方案的優缺點，最後總結相對於 nginx，更傾向於 envoy。首先 envoy 就是為微服務而生的負載勻衡工具，grpc 健康檢查是微服務中重要的一環。但是 nginx 擁有活躍的社群，說不定不久將來也會有支援 grpc 健康檢查的外掛。
在 Golang 中操作 Istio 和其他 CRD : 本文以 Istio 為例，演示如何使用 Golang 來對 Kubernetes 中的 CRD 資源進行增刪改查。
服務監聽 pod id 在 istio 中路由異常分析 : 在 Istio 服務網格中，絕大部分場景下使用者服務程式監聽的 ip 是 0.0.0.0，這種服務可以透明加入 istio 服務網格，但是如果使用者程式監聽的本機具體 ip(pod ip)，這種服務就無法直接加入當前 isito 服務網格，因為在 Envoy 的 inbound cluster 配置中，socket_address 被寫死了，值為 127.0.0.1。本文描述瞭如何嘗試修復這個問題。
使用 Kyverno 定義 Kubernetes 策略 : Kubernetes 的日常使用過程中，在物件提交給叢集之前，我們會有很多機會，很多方法對資源的 Yaml 定義進行檢查和處理。很多讀者應該也會知道，資源提交之後，還有機會使用 Admission Controller 對資源動動手腳，這其中其實有很多可以提煉出來的標準動作，可以用統一的控制器來進行處理，Kyverno 就是這樣一個工具。有了 Kyverno 的幫助，YAML 程式設計師可以根據條件對資源進行篩選。
3. 視訊推薦
只有大氣磅礴的 BGM，才配得上史詩級的《權力的遊戲》。So，只有大氣磅礴的 BGM，才配得上雲原生時代的作業系統。
4. 電子書推薦
CIS Kubernetes Benchmark : 該文件提供了一份為 Kubernetes 1.13 建立安全配置的說明指南，主要用來幫助應用管理員、安全專家和平臺部署人員規劃在 Kubernetes 平臺上開發部署應用的解決方案。
獲取方式：公眾號後臺回覆：kubernetes benchmark
5. 福利篇
ENFI下載器 : 這可能是最騷的百度網盤不限速下載器，不僅能為你提供高速下載，還能同時讓你賺取收入，支援 Windows 和 MacOS 哦。來看看我賺的錢：
下載速度基本滿速，具體取決於你的頻寬：
測試連結：https://pan.baidu.com/s/1JlsJsTN0JpwzA3DUzvyeIA 提取碼: 7uak
Pandownload 網頁版 : 這可能是最沒有存在感的百度網盤不限速下載工具。用過 Pandownload 的同學都知道，這是一款老牌的百度網盤第三方下載器。但是它只有 Windows 版本的客戶端，macOS 使用者只能無奈地搖搖頭。最近 Pandownload 推出了網頁版本，前段時間測試了一下確實好用，只需輸入百度網盤下載連結和提取碼，即可高速下載，親測可以跑滿頻寬。相比之下，比下載各種客戶端算是解決了 Mac 使用者不支援的福利。
還嫌不夠方便？沒關係，熱心網友開發了一款油猴指令碼，可以將百度網盤分享連結自動跳轉到 PanDownload 網頁版去下載。指令碼地址：百度網盤不限速直鏈下載
baidu-netdisk-downloaderx : 另一款圖形介面的百度網盤不限速下載器，支援 Windows、Linux 和 Mac。又是 Golang 寫的，不多介紹了，自己看吧。
