➤ 容器錯誤隔離排查
擁抱容器的主要優點之一是“輕量級虛擬化”。 由於每個容器只是容器化過程的薄層，使用者可以獲得巨大的效率，例如通過增加每個主機的容器密度，或以非常快的速度將容器擴充。 然而，正如本文中的故障排除故事將顯示的那樣，這種輕量級虛擬化的代價是在所有容器之間共享底層核心，在某些情況下，這可能會導致容器使用者通常考慮不到的不良影響。 這個故障排除故事涉及很多。 我將從基礎開始，之後再處理了更復雜的情況，希望讀者能從中獲得更多價值。
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 吉祥物。