今天，我们非常高兴地提出Sysdig 2019容器使用情况报告 （ Sysdig 2019容器使用情况报告 ）。 Kubernetes继续获得发展势头，云体系结构也在不断探索，所有这些不仅改变了使用模式，还改变了流程和组织结构。 令人惊讶的是，今年集装箱的数量增加了一倍，其寿命不超过5分钟。 服务变得越动态，更好的云团队就会认识到将安全集成到DevOps流程中的需求。 作为我们2019年使用情况报告的一部分，除了有关客户如何使用容器，Kubernetes等的许多详细信息之外，我们还将首次探索安全性和合规性详细信息。
独特的Sysdig位置
Sysdig Secure DevOps平台提供了有关基础结构，应用程序和容器的真实视角。 我们的报告涵盖了全球和许多地区的公司。 今年，我们提供了有关SaaS和Sysdig本地用户的详细信息，以向您展示部署了200万个容器的商业用途的示例。
有关结果的更多信息。
在我们的2018年报告中，我们描述了开放容器倡议（OCI）如何帮助引入替代性容器启动环境。 在2019年，这发生了大规模：集装箱项目占据了18％的重要份额。 公平地说，值得注意的是Docker使用了containerd。 以前，它的引擎同时实现了启动环境的高级功能和低级功能。 现在，它们分为两个独立的项目：containered和runc。
CRI-O今年首次亮相。 除其他外，我们对今天的低水平发展感到惊讶。 CRI-O是Kubernetes的轻量级运行时，于2016年出现在Red Hat上，并于2019年被CNCF©接受。 我们认为，一旦Red Hat OpenShift用户从v3迁移到v4，CRI-O将取代以前采用的Docker引擎，开发水平就会提高。
物理服务器上的容器密度正在以100％的速度增长
在过去的一年中，每台物理服务器的平均容器数量已增加到30个，比2018年的15个和2017年的10个增加了一倍。
我们认为，这一数字将基于以下几个因素而增加：
- 迁移到云基础架构的应用程序数量增加；
- 包含来自运行大型和密集集群的本地Sysdig客户端的数据；
- 计算“马力”的增长，允许更多的容器在每台服务器上工作。
2019年，每个节点的最大容器密度为250，与2018年相比增加了38％。
容器乐团：Kubernetes独领风骚
毫无疑问，作为事实上的编排工具，Kubernetes占据了二手编排器多达77％的份额。 如果添加基于Kubernetes构建的Red Hat OpenShift和Rancher，则该数字将增加到89％。 这是目前的数字情况：
如果为在本地部署Sysdig平台的公司分离数据，则业务流程的情况将发生很大变化。 在这一部分中， 红帽OpenShift容器平台处于领先地位。 主要原因是，通常规模较大且谨慎的用户组织希望利用Kubernetes，但更喜欢通过商业支持的本地解决方案（如平台即服务（PaaS），如OpenShift）来实现这一点。
同样在2019年的报告中，我们检查了有关公共云使用的统计数据。 下载以获取详细信息 。
安全与合规
“提前实施安全性”已经成为一个强迫症。 它描述了一种在开发生命周期的早期阶段嵌入安全性的方法。 通常，容器组织了解如何将安全性和合规性集成到DevOps工作流程中。 为了深入了解容器和Kubernetes中的安全性和合规性，我们从扫描漏洞，启动环境的安全性和CIS合规性等方面分析数据。
漏洞管理
客户端扫描图像以检测，阻止和消除CI / CD管道和容器注册表中的容器漏洞。 在完整的报告中，我们查看使用的注册表，从公共和私人存储库中提取图像的百分比。 我们还给出了成功/失败扫描图像漏洞的比率。 这里有一些结论。
图像提取：公共存储库与私有存储库
从公共或私有存储库中检索了多少个容器？ 我们发现40％的图像来自公开来源。
使用来自开放存储库的容器映像很麻烦-因为只有其中几个符合标准或经过检查是否存在安全漏洞。 以Docker Hub为例：标记为“ Certified”，“ Official”和“ Verified Publisher”的图像更值得信赖。 但是，在服务器上托管的300万张图像中，只有不到1％的图像具有这种名称。 为了降低风险，云团队创建策略来确定可以批准在其组织中使用的容器注册表。
影像扫描
无论采用何种来源，在将映像部署到生产环境中之前先扫描映像中的已知漏洞都是不可忽视的最佳实践。 为了评估风险或漏洞的程度，我们对通过和未通过扫描的图像进行了抽样，并扫描了5天。 一半以上的图像未通过测试，这意味着在其中识别出已知的高度和非常高危险等级的漏洞。
安全风险
开发人员解决已知问题之后，云团队必须建立确定异常行为的策略，并强制在生产环境中触发安全警报。 对于公司来说，Kubernetes的安全启动环境是新事物，但是他们很快就知道了什么。 在过去的一年中，CNCF的用于启动环境安全性的开源安全项目Falco从Docker Hub贡献了Sysdig 670万次。 这比上一年增加了252％。
我们从客户端从Sysdig Secure接收到的警报数量来看一眼策略违规，该警报通过Falco策略自动启动环境的安全性。 它确定了容器用户最常遇到的安全风险类型。 其中，最常见的是：
1-尝试访问敏感的卷，目录或文件； 2-入门时权限过多或尝试扩展权限； 3-从连接的终端启动命令外壳
在关于使用情况的完整报告中，我们详细检查了10种违规行为，并按频率对它们进行了排名，同时描述了每种违规行为，并解释了潜在威胁。
合规
为了降低风险并满足包括PCI-DSS，HIPAA和GDPR在内的合规标准，组织应使用最佳实践定期检查服务器和容器。 使用CIS内置基准对 Sysdig Secure中的Docker检查进行的审核显示，仍有改进的空间。 例如，我们发现通常在容器服务器上有：
十大开源容器解决方案
开源改变了企业范围数据处理的面貌。 它不仅推动整个基础架构的创新，而且尤其是在应用程序开发中。 Sysdig自动打开容器内部的流程，以查看构成我们的客户在生产环境中运行的云服务的解决方案。 以下是其中的前十名：
今年的新产品包括Node.js和Go（又名golang），它们在使用方面都领先于Java。 Java被认为是杰出的编程语言之一。 DevOps和云团队似乎更喜欢由Google工程师创建的更新选项，例如Go，部分原因是它们更易于使用。 例如，JavaScript框架Node.js使得编写在服务器和浏览器上均能正常工作的代码变得容易。 它还非常适合支持JavaScript编写的查询的新一代数据库，例如CouchDB和MongoDB。
容器寿命
容器生存时间（或更少），容器映像和服务的参数是我们2018年报告中最受欢迎的主题之一。 它反映了现代应用程序在开发和运行时方面如何更加动态。
容器寿命短
将容器的寿命逐年进行比较，我们发现寿命少于10秒的容器数量增加了一倍，达到22％。 同时，存活5分钟或更短时间的容器数量也增加了一倍。
许多容器需要很短的使用寿命才能满足其功能并立即自毁。 似乎还不够，但对于某些过程，则不需要更多。 我们相信，增加使用Kubernetes Jobs来执行这种增长的原因是Kubernetes Jobs可以执行批处理作业等最终任务。 更要说的是，我们期望低效率容器的数量将会增加，尤其是在非常适合运行短期任务的无服务器平台上。
容器的短暂特性是技术的独特优势之一。 同时，它极大地使诸如“查看安全性，性能和性能问题”之类的任务复杂化。 实时监控，安全性和合规性工具可根据短期流程提供实时可观察性，这是成功运营的关键。
图像的持续发展和寿命
容器是敏捷性的完美伴侣。 它们有助于加快代码的开发和发布速度，通常采用容器化微型证书的形式。 我们发现，在一周或更短的时间内，超过一半的容器映像已被替换或修订。 这表明如何缩短代码发布之间的时间。 此外，这表明CI / CD管道可以帮助开发团队以异常快的速度交付软件更新。
特殊代码指标
特殊的代码指标使DevOps开发人员和团队可以自定义代码以收集唯一的指标。 在过去的一年中，JMX，StatsD和Prometheus这三个基本解决方案中， Prometheus已成为可用性方面的领导者。 实际上，多年来，使用自定义指标的客户对Prometheus指标的使用增长了130％。 随着支持Prometheus的新编程框架的使用不断增长，JMX度量标准（用于Java应用程序）和StatsD的使用越来越少（今年分别为45％和17％）。
有关Sysdig客户使用的Prometheus的顶级指标和出口商，请参阅完整报告。
最高紧急设置
Sysdig客户的紧急设置清楚地表明了哪些云命令是对容器操作的最大威胁。 最常见的紧急情况已经转向支持Kubernetes基础架构，同时继续关注资源利用率和正常运行时间。 以下是分发给Sysdig客户端的800多种独特紧急设置中的前3名：
此外，可以为特定标签或云快捷方式/ Kubernetes配置警报。 说，使用上述警报中的示例，您可以将cpu.used.percent警报绑定到“ istio-system”类型的单个命名空间，或者绑定到命名空间中“ envoy”类型的特定Pod名称。 请参阅完整报告中的顶部警报绑定。
Kubernetes使用模式
用户管理多少个集群？ 每个节点上有几个吊舱？ 有人使用Kubernetes Jobs吗？ 2019年报告回答了这些问题和其他问题。 这是客户端使用Kubernetes进行部署的示例。
一些客户端仅安装几个群集-一个较大而稍微较小的群集，而其他客户端则安装了由许多不同大小的群集组成的庞大集群。 下表显示了Sysdig平台客户端的群集数分布和每个群集的节点数：
管理单个集群的大量客户或其中少数客户表明，许多企业才刚刚开始开发Kubernetes。 观察结果还受到公共云中使用Kubernetes托管服务的影响。 借助Amazon Elastic Kubernetes服务（EKS），Google Kubernetes引擎（GKE），Azure Kubernetes服务（AKS）和IBM Cloud Kubernetes服务（IKS）等服务，用户可以根据需要快速旋转和拆分集群。
每个群集的Pod数
Pod是Kubernetes中最小的可部署对象。 它们由一个或多个具有公用存储和网络的容器以及有关如何启动容器的规范组成。 以下是对Sysdig平台用户的分析：
重要！ 该表已更新，可以更正原始图像中的错误。 非常感谢Chris Collins-aka @ChrisInDurham-注意到了这个问题！
每个物理服务器的Pod数
物理服务器上的Pod一直存在，直到其所有过程完成为止，但是如果资源不足或物理服务器出现故障，则在移至另一台服务器时可以将其删除。 这是Sysdig平台用户向服务器分发Pods的快照：
完整报告中提供了有关Kubernetes命名空间，部署，StatefulSet和任务数量的信息。
结论
自上次使用报告以来，容器密度已经翻了一番，而且随着您的习惯，开发速度显然会提高。 我们第三份年度报告的主要结论强调，企业需要采取措施为预期的快速增长做准备：
- 组织应该在Kubernetes工具上进行投资以简化可扩展的操作。
- 实时可观察性为低生活水平的集装箱提供详细的审核和分析记录，对于操作的安全性至关重要。
- 为了克服运行时的风险，云团队必须立即采取行动-并将安全性集成到DevOps中。
- 随着Prometheus巩固其在云应用程序指标收集标准方面的领导者地位，用户应学习如何使用它，同时提供可靠性和可扩展性。
要了解所有详细信息，请下载完整的《 2019 Sysdig使用情况报告》 。