容器启动后短时间内关闭_为什么容器寿命这么短？

容器启动后短时间内关闭

我的雇主Sysdig最近对生产容器的部署进行的一项研究表明，有74％的容器的寿命少于一个小时，而有85％的容器的寿命少于一天，从表面上看，这似乎使容器看起来太短暂了做任何繁重的事情。

事实并非如此，但有趣的是更深入地研究容器的短暂而幸福的生活。 容器来回频繁的原因有很多，一些证据表明，随着时间的流逝，随着技术的成熟，容器的寿命可能会延长。

但这并不是说容器的寿命将与虚拟机的寿命一样长，虚拟机通常可以使用一个月。 容器是不同的品种，它们的独特属性带来了独特的用例，坦率地说，也带来了独特的挑战，特别是在管理和安全方面。

测试并杀死

容器寿命短的一个原因是该技术首先用于开发/测试环境。 您无需花三天的时间为应用程序设置测试环境，而可以使用容器快速对其进行设置，运行测试，然后转储该容器。

今天，这仍然是一个突出的用例，尤其是在具有连续集成/连续交付（CI / CD）环境的大型公司中。 据我所知，有一家公司为其在Jenkins应用程序构建系统中创建的每个工作都旋转一个容器，测试更改，然后关闭该容器。 每天要处理成千上万个容器。

让我们面对现实：公司要进行容器化的最后一件事就是数据库之类的东西。 容器非常适合批处理作业，例如工资核算处理或按计划运行的任务。 每天您都需要做一些分析并发送报告。 因此，您启动了一个容器，运行它，获取报告，然后终止该容器。 快速的工作，例如维护检查或备份，是人们首先将其容器化的事情，并且多数导致容器的寿命短。

但是，我看到在容器中运行的数据库解决方案（如PostgreSQL和MongoDB）的使用率有所增加。 随着容器生态系统的成熟，以及有状态集和持久性存储的发展，容器的生存期将来可能会增加。

窗帘后面的容器

但是，这个事实可能会被容器年轻的其他主要原因所掩盖：诸如Kubernetes之类的编排工具对容器基础结构进行了抽象。

编排人员可以在服务级别查看事物，这意味着底层基础结构不再重要。 您指定作业或任务需要多少CPU和内存，协调器将负责提供容器资源以满足作业要求。 如果途中出现打ic，可能会旋转一个新的容器并将有问题的容器杀死。

通过将协调器用作控制平面，可以根据需求即时添加或删除容器，从而造成容器流失。 在微服务架构环境中，自动缩放是应用程序的固有特性，应用程序组件可能分散在整个基础架构中，其结果甚至更加夸张。

这种趋势的发展是向无服务器环境（例如AWS Lambda）迈进，您甚至无法访问基础架构。 您的代码作为一个函数运行，并且引擎盖容器的下面将支持这些函数。

应对新现实

尽管编排工具有助于容器的使用，但它们并不能消除IT人员能够在幕后看到的需求。 例如，Sysdig Monitor可以确定服务的性能，这是关键，但是它也可以显示容器的运行状况，例如，揭示一些容器的运行状况以及原因。

随着容器环境的成熟，某些容器的寿命可能会比今天的年轻表亲更长，但是容器的独特属性和独特的使用方式意味着容器将不再像当今流行的更重，更难管理的虚拟机那样被使用。 因此，必须面对新兴的容器环境带来的新的管理和安全挑战。

翻译自: https://www.infoworld.com/article/3293260/why-are-containers-so-short-lived.html

容器启动后短时间内关闭