來自 SDXCentral 的調查：一年以內部署容器的人數增加了562%｜航海日誌 Vol.26

➤ 來自 SDXCentral 的調查，一年以內部署容器的量級增加了562%

來自 SDXCentral 的2017年集裝箱和雲計算報告的重要發現之一是，對於容器技術的部署在過去兩年中穩步增加，而且將在應用平臺領域超越虛擬機（VM）。在 2016 年，只有 8％的受訪者部署容器，而今年有 45 ％已經在使用。

該報告着重於雲計算和自動化領域，關注了企業和其餘受訪者面臨的挑戰。其中，有 62% 的受訪者採用容器技術的主要緣由是由於其使用的效率；有 58%的受訪者是由於其比虛擬機的開銷更低；同時有 47%的受訪者是由於其更易於管理。經過將應用程序從底層基礎結構中分離出來, 以及標準化的升級機制, 這些特性讓應用程序的測試和部署速度更快, 同時具有更高的應用程序可移植性和更好的安全性。

同時，最受歡迎的編排平臺是 Kubernetes 佔比爲 64％，Docker Swarm 佔比爲36％，Apache Mesos / Mesosphere 佔比爲18％。最初在 Google 開發的 Kubernetes 具備良好的行業支持，而且是 CNCF 項目的一部分。Docker 公司開發的 Docker Swarm 針對Docker Engine 進行了優化，並在 Docker Swarm 之上創建了一個管理堆棧。Docker 還與微軟合做，支持內置於 Windows Server 2016 和 Microsoft Azure 。

➤ Kubernetes 1.8.0 alpha.3 測試版本發佈

Kubernetes 距離 alpha2 發佈過去1個多月後，Kubernetes 1.8 第 3 個測試版 alpha.3 已經發布了，這次相比 alpha2 更新的內容較多主要一些變化有：

• 刪除無用的 kubectl 命令 apiversions, clusterinfo, resize, rollingupdate, run-container, update

• 從 kube – controller – manager 中刪除無用的 flags : replication-controller-lookup-cache-size, replicaset-lookup-cache-size, and daemonset-lookup-cache-size
  

• Beta 版的 Annotations service.beta.kubernetes.io/external-traffic 和service.beta.kubernetes.io/healthcheck-nodeport 已刪除。（請使用 service.spec.externalTrafficPolicy 和 service.spec.healthCheckNodePort 代替）

• 使用AWS提供的羣集須要使用 ClusterID 標記 nodes 和 resources 。

• RBAC：該 system:node Role 再也不自動授予新集羣的 system:nodes Group。建議使用 Node 受權模式受權節點。

• StatefulSet：刪除 pod.alpha.kubernetes.io/initialized Annotation 。

• 從 kube-apiserver 中刪除 –insecure-allow-any-token 。

• 將默認的 kubeadm bootstrap token TTL 從無限時長更改成 24 小時。若是依舊但願使用以前的 TTL，請使用 kubeadm init –token-ttl 0/ kubeadm token create –ttl 0。

➤ Docker 小貼士：拆分 Dockerfile 中的長指令行

拆分 Dockerfile 中的長指令行可以使 Dockerfile 更容易閱讀。讓咱們來看看這是如何作的。

就我來講，在編碼或處理配置文件時，我儘可能限制每行79個字符。它不只僅是一個標準，並且也剛好是我在2560x1440顯示器上的Sublime中溫馨地打開3個窗口的完美寬度。

在編寫Dockefile的時候，你可能會將命令高效的鏈接在一塊兒。可是，這樣作會致使指令行變的至關長。

舉例來講，看看這個122字符的命令：

RUN wget -O myfile.tar.gz http://example.com/myfile.tar.gz && tar -xvf myfile.tar.gz -C /usr/src/myapp && rm myfile.tar.gz複製代碼

在代碼編輯器中，這將所有在1行中顯示。水平瀏覽這一整行命令是至關費力的。

然而，咱們能夠把它拆分開來

RUN wget -O myfile.tar.gz http://example.com/myfile.tar.gz \
    && tar -xvf myfile.tar.gz -C /usr/src/myapp \
    && rm myfile.tar.gz複製代碼

這樣看起來是否是清楚多了？

反斜槓是在類Unix操做系統上將長行分解成多行的標準方法。因爲大多數Docker鏡像是使用某種形式的Linux基本鏡像構建的，因此反斜槓在這裏也適用。趕忙在你的Dockerfile中嘗試一下吧！

➤ 容器監控簡介

容器讓咱們的工做變的更加輕鬆容易，不管是對於開發或者生產。然而，與以前的開發模式相比，容器化也帶來了新的問題。容器監控是一個徹底不一樣的「猛獸」，讓咱們來看看緣由所在。

容器監控的不一樣之處

您如今已經建立並部署了兩個容器。如今須要作什麼呢？我須要在個人容器中安裝一個監視代理來監控容器內部的狀況？

不！容器的優勢之一是部署的容器的大小。咱們只安裝保證容器正常運行的那些必須的東西。很少很多。

容器的壽命比虛擬機要短得多。根據最新的DataDog Container調查，容器的平均壽命爲2.5天。如此高的變化率，咱們的監控軟件徹底不能跟上咱們修改應用的速度。

此外，容器使應用的橫向擴展和恢復變的很是容易。咱們須要瞭解容器狀態的更改和全部應用運行實例的位置。咱們監控系統必須可以應對這些變化，而且在應用擴展和恢復時進行快速跟蹤。

監控容器

容器的監控是無代理的。也就是說，咱們不會在監視器中安裝監控代理。一般，咱們在每一個主機上的容器的workload旁邊的附加容器中運行監視軟件來監視容器。這些監視容器用於監視主機和容器。

在這一點上，許多人混淆頭腦，問「另外一個容器是如何監視主機和主機上運行的容器的？」 大多數監視容器將根目錄從主機掛載到容器。經過掛載根目錄，監視應用將在進程狀態發生改變時更新，反之亦然。咱們爲何要關注進程而不是容器？容器就是進程，這是監控應用程序經過了解進程什麼時候轉換爲統計信息以及進程與應用程序之間的關聯的神奇之處。

哪一個是最好的監控解決方案？

選擇正確的監控解決方案不只僅是開源 vs. 商業產品。選擇解決方案時要謹慎考慮的問題--解決方案是否與容器協調器集成在一塊兒，是否基於雲，是否運行內部部署，是否應用集成，以及社區是否支持。這些主題中的每個自己均可以成爲選擇解決方案的決定性因素。若是您想進一步探索這些主題，請了解 Docker 容器的監控和管理。

爲了更好地協助您的決策過程，我建立了一個監控解決方案 Spider Graph Google 電子表格，以幫助您將目標與不一樣的產品進行可視化。

監控解決方案圖說明：

值範圍從 1(最不重要)到 5(最重要)。

• 「監控目標」行是每一個類別的基準

• 填寫 Coloumn A 中的名稱，並與監控解決方案進行比較

• 使用 Spider Graph 來肯定不一樣解決方案的功能

• 將目標基準值與不一樣的解決方案進行比較

您能夠將監視解決方案 Spider 圖進行比較。

總結

通過比較，您應該更加了解哪一個監控解決方案最適合您的項目了。

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

參考連接

• https://www.infoq.com/news/2017/08/containers-sdxcentral-survey

• https://www.kubernetes.org.cn/2581.html

• https://nickjanetakis.com/blog/docker-tip-17-breaking-up-long-lines-in-your-dockerfile

• https://www.brianchristner.io/introduction-to-container-monitoring/

做者介紹

莫非 Beck：DaoCloud 微服務攻城獅，吃飽了就困的一流段子手。

劉璽元 Boring：DaoCloud 市場部門（僞）萌新程序猿。

▼ 點這兒，查閱上一期的航海日誌