近日，容器創(chuàng)業(yè)公司 Sysdig 發(fā)布了 2019 年容器使用報告。這是 Sysdig 第三年發(fā)布容器年度使用報告，與之前不同的是，今年的調(diào)查結(jié)合了更多的數(shù)據(jù)源，并深入挖掘了 Kubernetes 的使用模式。

[[282546]]

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

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

容器運行時

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

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

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

容器編排平臺

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

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

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

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

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

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

容器的安全性

隨著容器工作負載進入到生產(chǎn)環(huán)境中，企業(yè)開始意識到要將安全性集成到 DevOps 工作流中。為了深入了解 Kubernetes 和云原生環(huán)境中的安全性，本次調(diào)查分析了包括漏洞掃描、運行時安全性在內(nèi)的相關(guān)數(shù)據(jù)。

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

容器注冊中心

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

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

鏡像掃描

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

大家都在運行哪些服務(wù)?

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

上圖中的開源解決方案覆蓋范圍很廣，但其中每項服務(wù)都對現(xiàn)代應(yīng)用的功能至關(guān)重要：

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

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

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

自定義監(jiān)控解決方案

自定義指標的監(jiān)控解決方案已經(jīng)成為了監(jiān)控云生產(chǎn)環(huán)境中應(yīng)用程序的流行方法。在我們的調(diào)查中，比較主流的三種解決方案分別是 MX、StatsD 和 Prometheus，其中 Prometheus 以 46% 的占比成為使用最多的解決方案。

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

容器的相關(guān)調(diào)查

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

企業(yè)內(nèi)部的容器規(guī)模

為了了解到目前企業(yè)內(nèi)部的容器規(guī)模，Sysdig 查看了每個客戶在其基礎(chǔ)設(shè)施上運行的容器數(shù)量。根據(jù)結(jié)果顯示，近一半用戶的容器規(guī)模在 250 個以下，同時有 9% 的用戶在管理著數(shù)量超過 5000 個容器。

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

容器密度

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

出現(xiàn)這種的主要原因可能是：

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

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

容器、鏡像和服務(wù)壽命

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

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

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

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

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

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