是什么导致无服务器的冷启动？

Question

我已经阅读了足够多的关于无服务器冷启动的论文，但还没有找到关于冷启动的原因的明确解释。你能试着从商业和开源平台的角度来解释它吗？

1. 商业平台，如AWS或Azure功能。我知道，对于我们
2. 来说，它们更像是一个黑匣子，还有一些开源平台，比如OpenFaaS、know或OpenWhisk。这些平台也有一个冷启动问题吗？

我对冷启动延迟的最初理解是花在旋转容器上的时间。在容器上升后，如果还没有被杀死，它可以被重用，所以有一个温暖的开始。这种理解真的是真的吗？我试着从映像本地运行一个容器，不管图像有多大，延迟都接近于零。

图片下载时间也是冷启动的一部分吗？但是不管在一个节点上发生了多少冷启动，只需要下载一个映像，所以这似乎没有意义。

也许是另一个问题，我也想知道当我们从图像中实例化一个容器时发生了什么？在此阶段，可执行文件及其依赖库(例如Python库)是否从磁盘复制到内存中？如果基于同一图像有多个容器怎么办？我想应该有多个副本从磁盘到内存，因为每个容器是一个独立的进程。

Answer 1

有很多级别的“冷启动”都会增加延迟。最热的路径是容器仍在运行，可以将其他请求路由到它。最冷的是一个全新的节点，所以它必须拉出图像，启动容器，注册到SD，等待无服务器飞机的路由更新，如果你挖得够深的话，可能会有更多的步骤。其中有些是并行的，但大多数都不能。如果吊舱因为没有被使用而被关闭，下一次运行在同一台机器上，那么是的，kubelet通常跳过拉图像(除非imagePullPolicy总是被迫在某个地方)，这样你就能得到更快的发射速度。不过，K8s的调度程序一般不会为此进行优化。