问题描述
我已经阅读了足够多的关于无服务器冷启动的论文，但还没有找到导致冷启动的明确解释。您能否尝试从商业和开源平台的角度解释一下？
- 商业平台，例如 AWS Lambda 或 Azure Funtion。我知道它们对我们来说更像是一个黑匣子
- 有一些开源平台，例如 OpenFaaS、Knative 或 OpenWhisk。这些平台是否也存在冷启动问题？
我对冷启动延迟的初步理解是花在启动容器上的时间。容器启动后，如果还没有被杀死，可以重用，所以有一个热启动。这种理解真的正确吗？我尝试从镜像本地运行一个容器，无论镜像有多大，延迟几乎为零。
图片下载时间也是冷启动的一部分吗？但是无论一个节点发生多少次冷启动，都只需要下载一次图片，所以这似乎没有意义。
也许是一个不同的问题，我也想知道当我们从图像实例化一个容器时发生了什么？在此阶段，可执行文件及其依赖库（例如 Python 库）是否从磁盘复制到内存中？如果有多个容器基于同一个镜像怎么办？我猜应该有多个从磁盘到内存的副本，因为每个容器都是一个独立的进程。
解决方法
有很多级别的“冷启动”都会增加延迟。热路径中最热的是容器仍在运行，并且可以将其他请求路由到它。最冷的是一个全新的节点，所以它必须拉取镜像，启动容器，注册 SD，等待无服务器平面的路由内容更新，如果你挖掘得足够深，可能还有更多的步骤。其中一些可以并行发生，但大多数不能。如果 pod 因为没有被使用而被关闭，并且下一次运行计划在同一台机器上，那么是的，kubelet 通常会跳过拉取镜像（除非在某处强制使用 imagePullPolicy Always），这样您的启动速度会更快一些。不过，K8s 的调度程序通常不会为此进行优化。