深圳幻海软件技术有限公司 欢迎您!

2019年容器使用报告:Docker 和 Kubernetes 王者地位不倒!

2023-02-27

 近日,容器创业公司Sysdig发布了2019年容器使用报告。这是Sysdig第三年发布容器年度使用报告,与之前不同的是,今年的调查结合了更多的数据源,并深入挖掘了Kubernetes的使用模式。据了解,本次调查包括了200多万个部署在企业生产环境中的容器使用情况,Sysdig不但首次整合

 近日,容器创业公司 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%

出现这种的主要原因可能是:

  1. 过渡到云原生基础设施的应用程序数量不断增长;
  2. 参与本地 Sysdig 客户的数据来自于更大、更密集的集群;
  3. 计算马力的增加,使得更多容器能够在单个节点上运行。

虽然容器的主要目标是加速开发和部署,但是容器效率的提高,同样帮助企业提高了硬件资源的利用率,在调查中,有受访者表示:“从跨节点集群过渡到容器,延长了现有硬件的寿命。”

容器、镜像和服务寿命

 

 

容器的寿命是大家一直都很关注的话题,之前我们经常提到大多数容器的寿命可能不到一周,但是根据我们的调查,很多容器的寿命时间要更短,22% 的容器存活期只有 10 秒或者更短的时间,在一周的时间内,容器的停止率可以达到 8%。

为什么会出现这种情况呢?我们注意到了 Kubernetes 的自动缩放功能,一旦服务需求减少,Kubernetes 就会自动减少每个服务的运行实例数量,而大多数容器只需要执行一个函数,当该函数执行完成之后就会停止。秒级虽然看起来很短,但对于某些进程来说,可能就已经是任务的全部了。

Sysdig 认为短寿命容器的数量在未来还会继续增加,尤其是在适合运行短期任务的无服务器平台上。

容器镜像的寿命反映了代码发布和 CI/CD 帮助开发团队交付软件更新的时间。根据调查结果显示,超过一半的容器镜像会在一周,甚至是更短的时间内被替换,代码部署越频繁,容器镜像的更新越快。

 

 

 

对于企业来说,系统保持 7*24 小时的运行是很重要的,因此我们也调查了服务的正常运行时间。这里的服务主要指的是应用程序的功能组件,例如数据库软件、负载均衡器、自定义代码等等。

根据调查结果显示,超过半数的受访者的客户服务都能保持连续两周以上的不间断运行。在底层,容器可能会因为支持扩展和其它操作暂时停止,但是应用程序会一直保持运行。随着代码发布频率的增加,容器及其解决方案仍然可以平稳执行回滚或灰度发布。