來自 SDXCentral 的調查：一年之內部署容器的人數增長了562％

最新 08-29

來自 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字元的命令：

在代碼編輯器中，這將全部在1行中顯示。水平瀏覽這一整行命令是相當費力的。

然而，我們可以把它拆分開來

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

反斜杠是在類Unix操作系統上將長行分解成多行的標準方法。由於大多數Docker鏡像是使用某種形式的Linux基本鏡像構建的，所以反斜杠在這裡也適用。趕緊在你的Dockerfile中嘗試一下吧！

容器監控簡介

容器讓我們的工作變的更加輕鬆容易，無論是對於開發或者生產。然而，與之前的開發模式相比，容器化也帶來了新的問題。容器監控是一個完全不同的「猛獸」，讓我們來看看原因所在。

容器監控的不同之處

您現在已經創建並部署了兩個容器。現在需要做什麼呢？我需要在我的容器中安裝一個監視代理來監控容器內部的情況？

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

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

此外，容器使應用的橫向擴展和恢復變的非常容易。我們需要了解容器狀態的更改和所有應用運行實例的位置。我們監控系統必須能夠應對這些變化，並且在應用擴展和恢復時進行快速跟蹤。

監控容器

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

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

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

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

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

監控解決方案圖說明：

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

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

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

使用 Spider Graph 來確定不同解決方案的功能

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

您可以將監視解決方案 Spider 圖進行比較。