近日，容器創業公司 Sysdig 發布了 2019 年容器使用報告。這是 Sysdig 第三年發布容器年度使用報告，與之前不同的是，今年的調查結合了更多的數據源，并深入挖掘了 Kubernetes 的使用模式。

[[282546]]

據了解，本次調查包括了 200 多萬個部署在企業生產環境中的容器使用情況，Sysdig 不但首次整合了用戶的使用數據(數據來自于通過 Sysdig Secure DevOps 平臺部署到的私人數據中心)，而且還從 IBM Cloud 提供的 Sysdig 服務中獲取到了使用情況的快照。

大家都在部署哪些容器平臺?

容器運行時

根據調查結果顯示：2019 年，Docker 占據了容器平臺市場的大部分份額，占比為 79%，而排在第二位的是 containerd，占比為 18%，排在第三位的 CRI-O 項目，占比為 4%。這個調查結果與信通院的國內市場調查結果有異曲同工之妙，國內近六成企業選擇 Docker 作為容器運行技術。

需要注意的是，containerd 是從 Docker 中剝離出來的容器虛擬化技術，CRI-O 是 Kubernetes 的輕量級運行時，最初是由 Red Hat 啟動，目前由 CNCF 托管。Sysdig 預測未來 CRI-O 的使用率會不斷升高，尤其是當 Red Hat OpenShift 的客戶從 v3 遷移到 v4 時，因為在 v4 版本中，CRI-O 取代了原來的 Docker 引擎。

雖然容器運行時的選型各不相同，但是大家在選型時的考慮事項大多集中在開銷、穩定性、可擴展性和容器注冊表兼容性這幾個方面。為了服務更多的用戶，流行的容器平臺例如 OpenShift、GKE 和 IKS 等都并行了支持多個容器運行時。

容器編排平臺

根據調查結果顯示，Kubernetes 一騎絕塵，占據了 77% 的份額。排在第二名的 OpenShift 和排在第五的 Rancher 其實也是基于 Kubernetes 構建的，如果把這兩部分份額也合流到 Kubernetes 中，那么 Kubernetes 的份額將上升為 89%。

與去年相比，Swarm 的份額下降幅度很大，從 11% 降至 5%。而 Mesos 的市場份額穩定在 4% 左右。

本地用戶和云用戶分別會選擇哪個編排平臺?

因為企業規模、風險規避等原因，不同的企業采用的編排平臺也會有所不同。根據調查結果顯示，43% 的受訪者會采用 Red Hat 的 OpenShift 作為本地容器編排平臺，因為這樣既可以享受到 Kubernetes 的優勢，同時又可以使用 OpenShift 商業支持的本地 PaaS 解決方案。

如果是云用戶，他們會選擇哪個云平臺呢?根據調查結果，73% 的受訪者選擇了 AWS。當然這也是有原因的，首先 AWS 在公有云領域、IaaS 領域擁有很大的市場份額，其次，Sysdig 與 AWS 有很多合作，這也在一定程度上使得 AWS 的調查結果比較靠前。

另外，這次調查還反映出另一個事實，11% 的用戶是采用多云的，他們會操作和監控多個公有云中運行的容器集群。

容器的安全性

隨著容器工作負載進入到生產環境中，企業開始意識到要將安全性集成到 DevOps 工作流中。為了深入了解 Kubernetes 和云原生環境中的安全性，本次調查分析了包括漏洞掃描、運行時安全性在內的相關數據。

一般來說，用戶都會通過鏡像掃描來識別、阻止和解決 CI/CD 管道和容器注冊中心中的容器漏洞。這次 Sysdig 的調查重點關注了正在使用的頂級注冊表和鏡像掃描尋找漏洞時的成功率或者失敗率。

容器注冊中心

容器注冊中心提供用于托管和管理容器映像的存儲庫,本次調查分為私有托管存儲庫和公有存儲庫兩個維度。

根據調查結果顯示，Docker 注冊表是最常用的，34% 的受訪者選擇了它，排在第二位的是Google GCR，28% 的受訪者選擇了它。另外，Sysdig 還查看了從公共存儲庫和私有存儲庫中提取的容器的百分比，比例為 2:3，使用來自公有存儲庫的容器鏡像，往往存在缺失驗證或檢查安全性漏洞的風險。

鏡像掃描

無論容器鏡像來自哪里，在部署到生產環境之前都需要執行鏡像掃描和識別已知的漏洞。為了量化漏洞風險的范圍，Sysdig 對 5 天內應用在生產環境中的鏡像進行了操作，其中有一半的鏡像失敗了，這意味著它們存在著嚴重程度更高的漏洞。

大家都在運行哪些服務?

容器中運行的開源解決方案 Top 10

上圖中的開源解決方案覆蓋范圍很廣，但其中每項服務都對現代應用的功能至關重要：

• http 服務器和反向代理解決方案：NGINX 和 Apache;
• NoSQL、關系型和內存數據庫解決方案：MongoDB、Postgres 和 Redis;
• 日志和數據分析：Elasticsearch;
• 編程語言和框架：Node.js、Go、Java/JVM;
• 消息代理軟件：RabbitMQ。

與之前相比，這次上榜的新事物是 Node.js 和 Go。和長期霸榜的 Java 相比，Go 語言還是一個小學生，但是由于易用性，Go 語言獲得了 DevOps 和云團隊的青睞。Node.js 能夠上榜的主要原因是簡化了在服務器和瀏覽器上的代碼編寫，同時支持新一代的數據庫，比如 CouchDB 和 MongoDB，支持使用 JavaScript 編寫的查詢。

需要注意的是，本次調查忽略了 Kubernetes 組件，如 etcd 和 fluentd，因為他們是默認部署的，幾乎是每個 Kubernetes 用戶的首選。

自定義監控解決方案

自定義指標的監控解決方案已經成為了監控云生產環境中應用程序的流行方法。在我們的調查中，比較主流的三種解決方案分別是 MX、StatsD 和 Prometheus，其中 Prometheus 以 46% 的占比成為使用最多的解決方案。

作為 CNCF 中最成功的開源項目之一，Prometheus 已經成為了云原生監控的代名詞，被廣泛應用在 Kubernetes、OpenShift 和 Istio 等項目中，同時有很多第三方解決方案也會集成 Prometheus。在 Sysdig 的用戶中，Prometheus 的使用量和去年相比，增長了 130%。

容器的相關調查

針對容器，Sysdig 每年都會關注并做相關調查，調查內容不僅能夠反映其對容器采用率的洞察，同時也在一定程度上反映了容器所實現的規模和效率。

企業內部的容器規模

為了了解到目前企業內部的容器規模，Sysdig 查看了每個客戶在其基礎設施上運行的容器數量。根據結果顯示，近一半用戶的容器規模在 250 個以下，同時有 9% 的用戶在管理著數量超過 5000 個容器。

在很多人看來，Kubernetes 和容器已經不是新鮮事兒了，但其實很多企業都是剛剛開始實踐，因此，在開始階段，容器數量比較少也是可以理解的，相信隨著 DevOps 和云團隊率先使用的帶頭效果，會有更多的部門開始關注容器。

容器密度

根據調查結果顯示，與去年相比，今年每臺主機中的容器數量增加了一倍，從 2018 年的 15 個增加到了 2019 年的 30 個。2019 年，單個節點的最大密度是 250 個容器，與 2018 年相比增加了 38%

出現這種的主要原因可能是：

1. 過渡到云原生基礎設施的應用程序數量不斷增長;
2. 參與本地 Sysdig 客戶的數據來自于更大、更密集的集群;
3. 計算馬力的增加，使得更多容器能夠在單個節點上運行。

雖然容器的主要目標是加速開發和部署，但是容器效率的提高，同樣幫助企業提高了硬件資源的利用率，在調查中，有受訪者表示：“從跨節點集群過渡到容器，延長了現有硬件的壽命。”

容器、鏡像和服務壽命

容器的壽命是大家一直都很關注的話題，之前我們經常提到大多數容器的壽命可能不到一周，但是根據我們的調查，很多容器的壽命時間要更短，22% 的容器存活期只有 10 秒或者更短的時間，在一周的時間內，容器的停止率可以達到 8%。

為什么會出現這種情況呢?我們注意到了 Kubernetes 的自動縮放功能，一旦服務需求減少，Kubernetes 就會自動減少每個服務的運行實例數量，而大多數容器只需要執行一個函數，當該函數執行完成之后就會停止。秒級雖然看起來很短，但對于某些進程來說，可能就已經是任務的全部了。

Sysdig 認為短壽命容器的數量在未來還會繼續增加，尤其是在適合運行短期任務的無服務器平臺上。

容器鏡像的壽命反映了代碼發布和 CI/CD 幫助開發團隊交付軟件更新的時間。根據調查結果顯示，超過一半的容器鏡像會在一周，甚至是更短的時間內被替換，代碼部署越頻繁，容器鏡像的更新越快。

對于企業來說，系統保持 7*24 小時的運行是很重要的，因此我們也調查了服務的正常運行時間。這里的服務主要指的是應用程序的功能組件，例如數據庫軟件、負載均衡器、自定義代碼等等。

根據調查結果顯示，超過半數的受訪者的客戶服務都能保持連續兩周以上的不間斷運行。在底層，容器可能會因為支持擴展和其它操作暫時停止，但是應用程序會一直保持運行。隨著代碼發布頻率的增加，容器及其解決方案仍然可以平穩執行回滾或灰度發布。