近日,容器創業公司 Sysdig 釋出了 2019 年容器使用報告。這是 Sysdig 第三年釋出容器年度使用報告,與之前不同的是,今年的調查結合了更多的資料來源,並深入挖掘了 Kubernetes 的使用模式。
據瞭解,本次調查包括了 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%
出現這種的主要原因可能是:
- 過渡到雲原生基礎設施的應用程式數量不斷增長;
- 參與本地 Sysdig 客戶的資料來自於更大、更密集的叢集;
- 計算馬力的增加,使得更多容器能夠在單個節點上執行。
雖然容器的主要目標是加速開發和部署,但是容器效率的提高,同樣幫助企業提高了硬體資源的利用率,在調查中,有受訪者表示:“從跨節點叢集過渡到容器,延長了現有硬體的壽命。”
容器、映象和服務壽命
容器的壽命是大家一直都很關注的話題,之前我們經常提到大多數容器的壽命可能不到一週,但是根據我們的調查,很多容器的壽命時間要更短,22% 的容器存活期只有 10 秒或者更短的時間,在一週的時間內,容器的停止率可以達到 8%。
為什麼會出現這種情況呢?我們注意到了 Kubernetes 的自動縮放功能,一旦服務需求減少,Kubernetes 就會自動減少每個服務的執行例項數量,而大多數容器只需要執行一個函式,當該函式執行完成之後就會停止。秒級雖然看起來很短,但對於某些程式來說,可能就已經是任務的全部了。
Sysdig 認為短壽命容器的數量在未來還會繼續增加,尤其是在適合執行短期任務的無伺服器平臺上。
容器映象的壽命反映了程式碼釋出和 CI/CD 幫助開發團隊交付軟體更新的時間。根據調查結果顯示,超過一半的容器映象會在一週,甚至是更短的時間內被替換,程式碼部署越頻繁,容器映象的更新越快。
對於企業來說,系統保持 7*24 小時的執行是很重要的,因此我們也調查了服務的正常執行時間。這裡的服務主要指的是應用程式的功能元件,例如資料庫軟體、負載均衡器、自定義程式碼等等。
根據調查結果顯示,超過半數的受訪者的客戶服務都能保持連續兩週以上的不間斷執行。在底層,容器可能會因為支援擴充套件和其它操作暫時停止,但是應用程式會一直保持執行。隨著程式碼釋出頻率的增加,容器及其解決方案仍然可以平穩執行回滾或灰度釋出。
報告下載連結:
https://sysdig.com/resources/papers/2019-container-usage-report/