我们有一个带有最新标签的基本图像。该基本映像正用于一堆应用程序。基本映像上可能会有一些更新，例如（OS升级，...）。当基础映像发生变化时，我们是否需要重建并重新部署所有应用程序？或者，由于标签是最新的，并且新的基础映像也将与标签最新，因此它将在docker层中进行更新，并且会在不重启的情况下得到照顾？
谢谢
答案 0 :(得分：4)
Kubernetes具有imagePullPolicy:设置来控制此设置。默认设置是，节点仅会在没有图像的情况下拉取图像，除非该图像使用的是:latest标签，否则它将始终拉取图像。
如果您有基本图像，然后有一些派生图像FROM my/base:latest，则派生图像将包括特定版本的基本图像作为其最低层。如果您更新基本图像并且不重建派生图像，则它们仍将使用相同版本的基本图像。因此，如果更新基本映像，则需要重建所有已部署的映像。
如果您正在运行某种形式的Pod，并且正在运行:latest标签，并且该标签指向更改的实际图像，则Kubernetes无法注意到这一点，因此您需要手动删除Pod来强制它重新创建它们。那很糟。 最佳做法是使用一些明确的非最新版本标记（可以使用日期戳），以便您可以更新部署中的映像，并且Kubernetes会为您重新部署。
答案 1 :(得分：2)
这个问题有两个层次。
Docker
如果您使用FROM baseimage:latest之类的图片，则该图片会在您的第一个版本中被下拉。 Docker在连续的构建中缓存层，因此它不仅会从相同的baseimage:latest构建，而且还会跳过Dockerfile元素的执行，直到第一次更改/未缓存一个。要使baseimage的构建通知发生更改，您需要在构建之前运行docker pull baseimage:latest，以便下一次运行使用latest标签下的新内容。
当版本化标记汇总次要/补丁版本时（例如，当您使用baseimage:v1.2时，版本标记也是如此），但软件会从baseimage:v1.2.3更新为v1.2.4，并通过相同的处理内容v1.2.4被发布为v1.2。因此，请注意如何处理特定图像的版本控制。
Kubernetes
使用:latest部署到Kubernetes时，通常需要设置imagePullPolicy: Always。对于上面的Docker构建而言，这意味着始终在运行之前拉映像。这远非理想，也不是一成不变的。根据容器重新启动的时刻，您可能最终会同时运行两个Pod，这两个Pod都相同:latest，而它们的:latest意味着其下的实际映像不同。
此外，您无法真正将Deployment中的图片从:latest更改为:latest，这显然不会导致更改，这意味着您无法触发滚动更新，除非您通过标签或其他形式的版本。
好的做法是以某种方式对映像进行版本控制，然后将更新推送到具有该版本的群集。这就是它的设计和一般使用的方式。我使用的一些版本控制架构是：
branch-buildnum或branch-sha-buildnum：我们经常使用它那并不是说我完全不使用最新的。实际上，我的大多数构建都是以branch-num的形式构建的，但是当它们发布到生产环境中时，它们也被标记并以branch-latest的形式推送到注册表（例如，产品为master-latest），这当您要使用当前生产版本部署新集群时，此功能非常有用（我们的头盔图表中的默认标签值指向最新的标签，并通过CI发布时设置为特定标签）