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

[[282546]]

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

大家都在部署哪些容器平臺(tái)?

容器運(yùn)行時(shí)

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

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

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

容器編排平臺(tái)

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

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

本地用戶和云用戶分別會(huì)選擇哪個(gè)編排平臺(tái)?

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

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

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

容器的安全性

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

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

容器注冊(cè)中心

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

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

鏡像掃描

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

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

容器中運(yùn)行的開源解決方案 Top 10

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

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

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

需要注意的是，本次調(diào)查忽略了 Kubernetes 組件，如 etcd 和 fluentd，因?yàn)樗麄兪悄J(rèn)部署的，幾乎是每個(gè) Kubernetes 用戶的首選。

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

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

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

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

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

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

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

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

容器密度

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

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

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

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

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

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

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

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

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

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

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