Kubernetes Recreate部署策略中如何减少拉取镜像导致的停机时间

Question

假设我有一个带有Recreate策略的Kubernetes部署对象，并且我使用一个新的容器映像版本更新了该部署。Kubernetes将：

1. 缩小/终止部署的现有Pods，
2. 创建新的Pods，
3. 它将拉取新的容器映像。
4. 这样新容器终于可以运行了。

当然，该Recreate策略预计会导致步骤 1 和 4 之间出现停机，此时没有Pod实际运行。但是，如果有问题的容器映像或容器注册表连接很慢，或者两者兼而有之，那么步骤3可能需要很长时间。在测试设置(Azure Kubernetes 服务从Docker Hub中提取Windows容器映像)中，我发现它需要5分钟甚至更长的时间，这将导致非常长的停机时间。

那么，减少停机时间的好办法是什么呢？我能否以某种方式让 Kubernetes 在上述步骤 1 中杀死 Pod 之前拉取新映像？（请注意，该解决方案应该适用于 Windows 容器，如果相关的话，Windows 容器非常大。）

在互联网上，我找到了这篇Codefresh文章在Docker中使用DaemonSet和Docker，但我猜Docker中的Docker不再与containerd兼容。

我还发现了这个StackOverflow的答案，建议将 Azure 容器注册表与 Project Teleport 结合使用，但这是私人预览版，尚不支持 Windows 容器。此外，它是特定于Azure Kubernetes服务，我正在寻找一个更通用的解决方案。

当然，这是一个有“标准”答案的常见问题吗？

2021-12-21更新:，因为我得到了相应的答案，所以我会澄清我不能轻易更改部署策略。所讨论的应用程序不支持同时运行不同版本的Pods，因为它使用的数据库需要迁移到相应的应用程序版本，不具有向前或向后兼容性。

Answer 1

实施“蓝绿色”部署策略。例如，服务可能在“蓝色”状态下运行并处于活动状态。使用一个新的容器映像创建一个新的部署，它使用新的容器映像部署“绿色”吊舱。当所有“绿色”吊舱准备就绪时，运行“开关活动”步骤，该步骤切换活动颜色。很少休息时间。

显然，这是有取舍的。您的集群将需要更多内存来运行额外的过渡吊舱。部署过程将更加复杂。

Answer 2

通过图像/，我发现了这些想法：

• 实现一个DaemonSet，在我需要的所有图像上运行一个“睡眠”循环。
• 使用http://github.com/mattmoor/warm-image，它不支持Windows。
• 使用https://github.com/ContainerSolutions/ImageWolf，上面写着："ImageWolf目前是alpha软件，打算作为PoC使用--请不要在生产中运行它！“
• 使用https://github.com/uber/kraken，这似乎是一个注册表，而不是预拉动解决方案。
• 使用https://github.com/dragonflyoss/Dragonfly (现在的https://github.com/dragonflyoss/Dragonfly2)，它似乎也做了一些完全不同的事情。
• 使用https://github.com/senthilrch/kube-fledged，它看起来非常正确，并且比其他的看起来更成熟，但是使用不支持Windows。
• 使用https://github.com/dcherman/image-cache-daemon，哪个不支持Windows。
• 使用https://goharbor.io/blog/harbor-2.1/，这似乎也是一个注册表，而不是预拉动解决方案。
• 使用https://openkruise.io/docs/user-manuals/imagepulljob/，它看起来也不错，但是( a) OpenKruise是巨大的，我不确定我是否只想安装它来预加载映像，和( b)它似乎是它不支持Windows。

所以，我似乎必须自己用DaemonSet来实现这一点。我仍然希望有人能提供一个比这个更好的答案。