我的雇主Sysdig最近对生产容器的部署进行的一项研究表明，有74％的容器的寿命少于一个小时，而有85％的容器的寿命少于一天，从表面上看，这似乎使容器显得太短暂了而无法做任何繁重的事情。
事实并非如此，但有趣的是更深入地研究容器的短暂而幸福的生活。 容器来回频繁的原因有很多，一些证据表明，随着时间的流逝，随着技术的成熟，容器的寿命可能会延长。
这并不是说容器的使用寿命将与虚拟机的寿命一样长，虚拟机通常可以使用一个月。 容器是不同的品种，它们的独特属性带来了独特的用例，坦率地说，也带来了独特的挑战，特别是在管理和安全方面。
测试并杀死
容器寿命短的一个原因是该技术首先在开发/测试环境中使用。 您无需花三天的时间为您的应用程序设置测试环境，而可以使用容器快速对其进行设置，运行测试，然后转储该容器。
今天，这仍然是一个突出的用例，尤其是在具有连续集成/连续交付（CI / CD）环境的大型公司中。 据我所知，有一家公司为其在Jenkins应用程序构建系统中创建的每个工作都旋转一个容器，测试更改，然后关闭该容器。 每天要处理成千上万个容器。
让我们面对现实：公司要进行容器化的最后一件事就是数据库之类的东西。 容器非常适合批处理作业，例如工资核算处理或按计划运行的任务。 每天您都需要做一些分析并发送报告。 因此，您启动了一个容器，运行它，获取报告，然后终止该容器。 快速的工作，例如维护检查或备份，是人们首先将其容器化的事情，并且多数导致容器的寿命短。
但是，我看到在容器中运行的数据库解决方案（如PostgreSQL和MongoDB）的使用率有所增加。 随着容器生态系统的成熟，以及有状态集和持久性存储的发展，容器的寿命可能会在未来增加。
窗帘后面的容器
但是，这个事实可能会被容器年轻的其他主要原因所掩盖：诸如Kubernetes之类的编排工具将容器基础结构抽象化。
编排人员可以从服务级别看待事物，这意味着基础架构不再重要。 您指定作业或任务需要多少CPU和内存，协调器将承担提供容器资源以满足作业要求的责任。 如果途中出现打h，可能会旋转一个新的容器并将有问题的容器杀死。
在协调器充当控制平面的情况下，可以根据需求即时添加或删除容器，从而造成容器流失。 在微服务体系结构环境中，自动缩放是应用程序的固有特性，应用程序组件可能分散在整个基础架构中，结果甚至更加夸张。
这种趋势的发展是向无服务器环境（例如AWS Lambda）迈进，您甚至在这里都无法访问基础架构。 您的代码是作为一个函数运行的，引擎盖容器的下面将支持这些函数。
应对新现实
尽管编排工具有助于容器的使用，但它们并不能消除IT人员能够在幕后看到的需求。 例如，Sysdig Monitor可以确定服务的性能，这是关键，但是它也可以显示容器的运行状况，例如，揭示一些容器的运行状况以及原因。
随着容器环境的成熟，某些容器的寿命可能会比今天的年轻表亲更长，但是容器的独特属性和独特的使用方式意味着容器将永远不会像今天流行的更重，更难管理的虚拟机那样被使用。 因此，必须面对新兴的容器环境带来的新的管理和安全挑战。
