由淺入深，帶你進行容器錯誤隔離排查｜航海日誌 Vol.19

➤ 容器錯誤隔離排查

擁抱容器的主要優勢之一是「輕量級虛擬化」。 因爲每一個容器只是容器化過程的薄層，用戶能夠得到巨大的效率，例如經過增長每一個主機的容器密度，或以很是快的速度將容器拓展。 然而，正如本文中的故障排除故事將顯示的那樣，這種輕量級虛擬化的代價是在全部容器之間共享底層內核，在某些狀況下，這可能會致使容器用戶一般考慮不到的不良影響。 這個故障排除故事涉及不少。 我將從基礎開始，以後再處理了更復雜的狀況，但願讀者能從中得到更多價值。

1.隔離：優勢

咱們從容器化的基礎開始，對於這些例子，咱們將使用很是熟悉的 Docker 容器運行時。因爲全部容器用戶都很是瞭解，一旦建立了一個容器，默認狀況下就會有很是大的隔離：容器化文件系統與外部隔離（經過安裝命名空間），容器中的進程就像是主機上只有一個（經過 PID 命名空間）等等。

還有一些附加選項，也能夠限制容器能夠消耗的物理資源量。這經過cgroup實現，而且在每一個主機部署多個容器時強加這些約束是相當重要的。例如，讓咱們運行兩個容器，確保第一個容器能夠只佔用系統 CPU 的10％：

$ sudo docker run --cpu-quota = 80000 --name container1 stress $ sudo docker run --name container2 stress

咱們使用 -cpu-quota 參數以絕對值（相對於個人 8 核心主機）來指定 CPU 限制，可是 cgroups 和 Docker 都支持其餘方法來設置這樣的限制，例如經過分配相對權重。而後，咱們可使用容器監控工具驗證限制是否正確執行：

CPU佔用百分比

事實上，第一個容器不能超過所有CPU消耗的 10 ％。監視容器的更多詳細信息，請參閱本文關於 CPU 和內存限制執行。 咱們也能夠將 Docker 容器內存使用限制爲 512 MB：

$ sudo docker run -m 512m - name container1 stress

運行一個能夠在Docker容器內快速分配內存的程序，咱們能夠看到該容器很快被殺死，Docker 生成一個容器 OOM（Out Of Memory）事件。

容器內存不足

這些是限制資源的基本原語：內核爲全部正在運行的容器執行它們，就像傳統的虛擬機管理程序同樣將它們應用於正在運行的虛擬機。然而，容器和內核之間的緊密耦合也帶來了其餘的挑戰，在下一節將進行探討。

2.隔離：缺點

前幾天，咱們的一位客戶遇到了一個問題：容器化應用程序的性能在很大程度上取決於哪幾個容器同時安排在同一主機上。 特別是當集羣控制者（在這種狀況下是 Kubernetes ）決定在主機上安排兩種特定類型的容器映像（咱們稱之爲「工做者」和「 trasher 」）時，容器化應用程序的性能將會緩慢而穩定地惡化。

首先，使用上面探討的 cgroup 原語，肯定容器在 CPU /內存/ IO 方面受到了適當的限制，這彷佛是微不足道的。 通過深刻檢查，事實證實，集裝箱已經受到 Kubernetes 限制，最重要的是，他們中沒有一個初始化就使用許多系統資源。 兩個集裝箱之間的衝突變的更加微妙起來。

//*想看完整內容請持續關注 DaoCloud ，咱們將後期在文章中發佈。*//

➤ Bucketbench：比較容器運行時性能

2016年， IBM 團隊建立了 OpenWhisk 無服務器平臺（如今是一個 Apache 孵化項目），但願挖掘基於 Docker 引擎的功能執行程序的一些性能問題。

通過一番討論，咱們須要一種方式來對容器生命週期事件和運行時組件進行比較。 鑑於據說過 runC 和 containerd，因而決定建立一個基於 Golang 的框架，以便針對一組可配置的容器引擎運行一系列的容器生命週期命令，因而誕生了 bucketbench。

目前，bucketbench 具備 Docker，runC 和 containerd 的驅動程序實現，特別是對於 containerd，有兩個驅動程序：一個使用 ctr 客戶端操做的是 0.2.x 分支（由當前的 Docker 引擎版本使用），另外一個驅動程序使用了目標 containerd 1.0 的 gRPC 客戶端庫，該庫將盡快發佈。每一個驅動程序實現如下生命週期命令：建立，運行，中止，刪除，暫停和恢復。 任何能夠實現這些簡單命令的容器引擎均可以做爲驅動程序實現添加到 bucketbench 中。

➤ 班加羅爾聚會 - Docker 網絡疑難解答演示

Docker 班加羅爾團隊很是活躍，致力於 Docker 及其周邊生態系統。 近日在 IBM 辦公室舉行了一次包括 Moby，Linuxkit，Windows Docker 和 Docker 多階段構建在內的多主題聚會。會議進行了「 Docker 網絡 - 常見問題和故障排除注意事項」的演示，重點思考了如下幾點：

網絡是一個複雜的主題，Docker 網絡在每一個版本中不斷髮展，這使得人們很難找出最佳實踐。

當應用從開發到生產，網絡需求發生變化，典型的方法並不老是有用。

企業客戶有許多遺留應用程序，而且網絡須要知足將舊的非容器應用與新的基於容器的微服務相鏈接。

相關連接：

幻燈片：

https://www.slideshare.net/SreenivasMakam/docker-networking-common-issues-and-troubleshooting-techniques

視頻：

https://www.youtube.com/watch?v=ChGBJysUAo8&feature=youtu.be

➤ Docker 監控：Docker 中監視 Java 應用程序的五大核心

在容器中運行應用程序是大型分佈式系統部署愈來愈流行的方式。 Java VM的特色使其成爲基於容器的基礎架構的理想語言。 經過衆多組件，在容器中監視 Java 應用程序須要規劃和選擇正確的工具來實現。

1. 使日誌更易用

固然，Java 本身能夠生成應用程序日誌，可是一般須要額外的工具來使它們更易於閱讀和使用。 有諸如 Splunk 和 Elastic stack 之類的成熟日誌收集處理工具，或者相對較小（但不遜色的）工具，如Sumo Logic，Graylog，Loggly，PaperTrail，Logentries和Stackify。

2. 性能監控

應用程序性能監視（APM）工具備助於識別代碼或基礎架構中的性能瓶頸。 這是一個複雜的系統，擁有諸如 AppDynamics，Dynatrace 和 New Relic 等衆所周知的工具，以及少許的開源選項。

3. 錯誤跟蹤

應用程序會產生錯誤，可是因爲今天覆雜的交織和分佈式代碼庫，一般很難直接找到錯誤的源頭。 錯誤跟蹤工具旨在經過監控生產中的應用程序來幫助您解決此問題。

4. 容器指標

容器本質上是小型，獨立的機器，因此相似的指標（如 CPU 和內存使用量）對於跟蹤高級應用程序問題仍然很重要。 我將主要在這裏覆蓋基於 Docker 的容器，可是會提到一個工具是否支持其餘選項。

5. 編排

隨着容器基礎設施變得愈來愈複雜，您須要編排工具來構建應用程序並根據需求進行更改，並在容器和機器遇到問題時保持一致性。 這個領域有一小部分主要參與者，它們都是提供衡量指標監控的解決方案，由於它是必不可少的組成部分。（譯者注：DCE 是您的好選擇 ）

➤ 英國伯明翰 Serverless Fusion 會議

Alex Ellis 前往英國的西米德蘭茲，首次訪問了 Fusion 聚會組，探討了如何開始使用功能即服務（FaaS）構建 Serverless 應用程序。

FaaS 是一個開源項目，歡迎貢獻，瞭解有關使用 FaaS 的 Serverless，請查看文後連接。

這一期的『航海日誌』就到這裏，下期再浪～

參考連接

• https://sysdig.com/blog/container-isolation-gone-wrong
  

• https://integratedcode.us/2017/06/29/bucketbench-comparing-container-runtime-performance

• https://sreeninet.wordpress.com/2017/07/02/docker-networking-troubleshooting-presentation

• http://blog.takipi.com/docker-monitoring-5-methods-for-monitoring-java-applications-in-docker/

• https://www.slideshare.net/AlexEllis11/zero-to-serverless-in-60-seconds-anywhere?ref=https://blog.alexellis.io/faas-at-fusion

  
  

做者介紹

夏巖：DaoCloud 技術顧問，僞の全棧工程師 && 語言愛好者。

楊雪穎 Misha：DaoCloud 技術顧問，能文能擼碼の通用型選手，兼 Labs 吉祥物。