雲原生週報：第 3 期

本文首發於：微信公衆號「雲原生實驗室」，公衆號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，才配得上雲原生時代的操做系統。

> 視頻觀看地址：https://www.yangcs.net/posts/cloud-native-weekly-3/

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 寫的，很少介紹了，本身看吧。