Sysdig 2021 容器安全和使用报告(下篇)

文章来源：Sysdig

译者：鸿臻

客户正在运行哪些服务?

在容器中运行的十大开源解决方案

开源改变了企业在云计算领域的面貌。它不仅推动了基础设施的创新，也推动了应用研发的创新。Sysdig能够自动发现容器内的进程，这让我们能够即时了解客户在生产中，运行云原生服务的解决方案。以下是Sysdig客户部署的十大开源技术:

2021年的榜单包括了各种各样的服务——每一种服务都对应用程序的功能至关重要，包括:

• http服务器和反向代理解决方案- NGINX

• NoSQL, 关系和内存数据库解决方案-MongoDB, Postgres和Redis

• 日志和数据分析——Elasticsearch

• 编程语言和框架 — node. js, Go, and Java/JVMs

• 消息队列代理软件 — RabbitMQ

开源社区中可供选择的范围尽管很广，但在我们记录列表中的服务在过去三年中保持了惊人的一致。我们有意省略了Kubernetes组件，如etcd、fluentd以及Falco。由于这些都是默认部署的，所以对于每个Kubernetes用户来说，它们都位于列表的顶部。去年，Node.js和Go(又名golang)的使用量都超过了Java。今年，Go的使用率从14%飙升至66%，增长了470%。由谷歌工程师创建的Go语言正在迅速成为开发云原生应用程序的首选语言。列表中前10的解决方案是用户普遍部署的可信服务。如果您正在市场上寻找类似的服务，那么您应该充分利用这些开源解决方案。

自定义指标

自定义指标解决方案为开发人员和DevOps团队提供了一种方法来收集独一无二的数据。这种方法已经成为在生产环境中监控应用程序的主流方法。三个主要解决方案是JMX、StatsD和Prometheus，其中Prometheus连续第二年获得了胜利。

与去年同期相比，我们的客户使用Prometheus指标的比例上升到了62%，而去年为46%。随着新编程框架的广泛使用，JMX指标(用于Java应用程序)和StatsD等替代指标继续下降，同比分别下降了35%和15%。

Prometheus exporters 排名

作为CNCF最成功的开源项目之一，Prometheus已经成为云原生服务监控的代名词。它现在被Kubernetes、OpenShift和Istio等项目作为监控指标广泛使用。此外，越来越多的“exporters”可以为大量的第三方解决方案提供详细的数据指标。在Sysdig为大规模环境提供完全兼容Prometheus的情况下，我们预计Prometheus的受欢迎程度将在我们的客户基础中持续增长。

对于当前的排名情况，我们查看了在prometheus.io上列出的每个github项目。并统计了每个项目的问题、星标数和forks的数量，并将结果与Dockerhub或其他仓库拉取数量相关联。

容器

每年，我们都要详细统计一下容器的数量和活动，还包括容器的密度和寿命。通过对容器的采样和研究，也验证了企业正在实现的规模和效率。

在每个团队中容器的运行数量

为了解企业当前的规模，我们调研了每个客户在其基础设施上运行的容器数量。超过一半的客户使用250个或更少的容器。在高端市场，只有4%的客户管理着超过5000个容器。大多数客户是从小规模开始慢慢累积的，也有一些是开发人员为推动容器化加速软件交付主动增加了规模。据DevOps和云计算团队报告称，一旦容器的优势得到证明，越来越多的业务部门会关注新的平台，这些平台普及的速度将会加快。然而，企业应该应该考虑运行容器的原始数量，以及这些容器的大小(见下图)。

镜像到底有多大?

尽管镜像的大小取决于应用程序，但根据我们的数据，镜像的平均值是376 MB。较大的10GB 镜像是一个极端值，除非有使用该镜像的场景，否则使用较大的镜像并不是最佳实践。大型镜像不仅需要更长的部署时间，还会降低发布速度，更可能会暴露更多的漏洞。

容器密度

每个主机的容器密度增加了33%!

在过去四年中，每一份报告中都显示容器数量中位数有所增加。然而，今年同比增幅仅为33%，而去年的增幅为100%。在将来这个数字可能会继续小幅增加，但这种密度的增加可能会以牺牲整体镜像大小为代价。尽管容器的主要目标是加速开发和部署，但在容器执行效率一定的前提下，许多团队正在提高硬件资源利用率以获取更好的效益。

容器,镜像,和服务的生命周期

在我们2019年的报告中，容器、容器镜像和服务的寿命长短是最受欢迎的数据报告之一。它从开发和容器运行时的角度反映了现代应用程序的活跃状态。

• 容器寿命短

通过比较容器每年的寿命，我们可以看到相似的数据，大多数容器的寿命都不到一周。事实上，我们最新的数据样本显示，与去年的22%相比，存活10秒的容器数量仍然保持在21%。

许多容器需要在整个生命周期中执行某个功能，功能完成时则终止容器。几秒钟可能看起来很短，但对于某些过程来说，这是必要的。容器的短暂性仍然是该技术的独特优势之一，但会对容器的监控、安全性和合规性方面提出了新的挑战。随着采用Serverless(无服务器架构)云技术的增长，较短寿命的进程和服务可能会从容器移向托管云。但是，这并不代表环境中工作负载总体架构会发生变化。相反，它可以代表寿命较短的工作负载从一种技术到另一种技术的转变。

• Continuous development and image lifespans

容器是敏捷开发的完美伴侣，它通常作为容器化的微服务加速代码开发进程和应用发布进度。据我们调研的镜像生命周期数据显示，代码发布和CI/CD流水线正在帮助开发团队更快的交付，超过一半的容器镜像在一周或更短的时间内被更替或删除。对于大多数企业来说, 进入市场的速度在保持竞争力方面起着至关重要的作用。随着代码频繁地被编译构建部署，这意味着不断产生着新的容器镜像，企业中不断涌现的灵感和想法将迅速转化为真实的容器运行在企业中。

• Service lifespan

在关乎寿命这个话题中我们最后检查了有关服务和运行时间的数据。服务是什么呢?它是我们软件的重要组成部分，比如数据库软件、负载平衡器和客户的代码，这些服务可能会不断的优化改进。然而，保持服务24小时运行是十分重要的(至少对大多数7*24 提供服务的企业来说确是如此)。与过去几年不同的是，我们有超过一半的客户服务持续两周或更长时间，今年我们在服务运行时间上看到了更多的变化，尤其是在不到5分钟范围内变化很大。

告警

对客户设置的告警类型进行趋势分析，有助于我们了解用户认为对其容器操作最有可能造成破坏的情况。

The top 10 告警策略

我们的客户使用了800多种独特的告警策略。下图表示最常用的告警策略，以及每种告警的占比。与上次报告相比，这些告警的组成已经发生了变化，大多转向了支持Kubernetes节点可用性，而略微减少了对资源利用率和正常运行时间的关注。

告警范围

Sysdig告警支持通过“限定”特定标签或Kubernetes / cloud标签进行定制。例如，使用上文中告警的一个例子，您可以为单个名称空间(如“isio -system”)或该名称空间中的特定Pod名称(如“envoy”)指定memory.used.percent字段。标签在云原生环境中扮演着关键角色，它是为团队提供隔离项目的唯一标识。

在本示例中，标签指定了一组“待观察的资源”。用Kubernetes标签指定告警现在是最常见的做法之一，前五名包括命名空间、集群、Deployment和host。代理标签——部署时附加到Sysdig代理上的元数据——成为了Sysdig用户中最流行的告警范围。

在下面的图片中显示了一些我们的客户正在使用的告警范围标签：

告警渠道

我们通过专门的通信通道查看了用户的告警信息。发现Slack位居榜首，超过了专用事件响应平台，甚至超过了电子邮件。这些结果更有趣的是与PagerDuty和Opsgenie不同，Slack并不被认为是一个事件响应平台。Slack大多用于处理工作时间内的非关键性警报，而像PagerDuty这样的解决方案被用于关键性警报，提供类似“把人们从床上叫醒”的服务。

今年，我们决定为未配置通知通道的告警添加一个类别。这种情形的出现是因为告警仅仅用于提供相关信息，也可能是因为Sysdig平台本身提供了足够的信息已经满足了告警的需求。

Kubernetes使用模式

客户正在运行多少个集群?每个节点运行多少pod ?在本节中，我们将回答这些问题以及更多内容。我们从集群维度到ReplicaSets维度调研了关于客户使用Kubernetes做了什么。由于Sysdig可以自动收集Kubernetes标签和元数据，我们能从性能指标、告警到安全事件中为我们发现的所有数据提供上下文。同理，我们可以通过简单的查询，从集群一直捕获到pod和容器的使用数据。

Kubernetes集群和节点

一些客户维护几个集群，他们的集群大小不一，而另一些客户则拥有许多不同规模的集群。下方的图表提供了Sysdig平台用户的集群数量和每个集群节点的分布。大多数客户只拥有单个集群，并且节点数量相对较少，这表明许多企业仍处于使用Kubernetes的早期阶段。我们还认识到，在公共云中使用托管Kubernetes服务是影响这 些数据点的另一个因素。这些服务提供商如:Amazon Elastic Kubernetes Service (EKS)、谷歌Kubernetes Engine (GKE)、Azure Kubernetes Service (AKS)和IBM Cloud Kubernetes Service (IKS)，用户可以根据需求快速启动和删除集群。

Kubernetes命名空间、deployments和pods

• 每个集群上的命名空间

Kubernetes使用命名空间来帮助多个用户、团队或应用进行资源隔离。Kubernetes有三个初始命名空间:default、kube-system和kubepublic。命名空间的使用方式因人而异，但云原生团队通常为每个应用使用单独的命名空间。

• 每个命名空间下的Deployments

Deployments描述了pods和replicassets所需的状态，并有助于确保应用的一个或多个实例来正常应对用户请求。Deployments包含一组多个相同的pod，它没有唯一的身份定义，比如NGINX、Redis或Tomcat都可以是Deployments。每个命名空间下的Deployments构成了用户微服务应用。

我们看到今年出现了轻微的变化，每个命名空间的Deployments数量减少了。通过命名空间对环境进行访问是简单有效的，因此，在每个命名空间中Deployments数量越少，越可以为团队更好地分工，让他们只能访问自己负责的应用。

• 每个集群中 pod 的数量

pod 是 Kubernetes 中最小的可操作对象。它们包含一个或多个具有共享存储和网络的容器，以及如何运行这些容器的定义。

• 每个节点中 pod 的数量

每个 pod 的整个生命周期都在将节点上完成，有时会因为节点资源不足或节点故障被驱逐至其他节点。

统计数据和数据来源

该报告中的数据来自于对近200万个容器的分析，这还是我们的客户每天运行容器的一部分。

我们又从GitHub、Docker Hub和CNCF等公共数据源中提取容器数据。这些数据来自于全球各行各业的容器使用情况，团队的规模从中型企业到大型企业不等。

结论

容器技术在应用交付中的作用日益显著。随着DevOps团队对Kubernetes关注度的提高，我们非常欣喜地看到团队在构建过程中贯彻和落实安全规范。但是，仍需要更多的保障来确保容器的安全，以防止可能出现的漏洞进入生产。在我们第四份年度报告中突出表明了容器环境趋势的持续增长，和对开源解决方案依赖的增强:

• 各个团队在Kubernetes环境中不断“向左移动”，通过在构建阶段利用内嵌扫描来扫描镜像，漏洞也不断地增多，仍需要有保障的安全工具来识别、审计和验证合规性。

• 尽管Kubernetes仍然是容器编排的最佳选择，但容器运行时的选择也在随着containd和CRI-O的快速增长而变化。随着容器密度的增加，团队应该在Kubernetes-native工具中多做贡献来简化大规模的操作。

• 一些开源的产品正在成为Kubernetes环境中的核心组件。Falco、Prometheus和Go的发展表明了人们对高质量开源解决方案的渴望，希望以此帮我们解决对于生命周期较短的容器安全和监控问题。

相关阅读：

Sysdig 2021 容器安全和使用报告(上篇)