如何很好地要求Kubernetes检索较新的图像？

Question

我有一个新的Docker映像，理想情况下，我希望对其进行平滑升级，或者忘记以前的部署版本，或者只保留以前的版本，而不保留所有先前部署的版本。

Kubernetes Pods将在重新启动后重新检索最新图像（如果标记为:latest或）imagePullPolicy: Always。

但是，除非image标签更改，否则操作a kubectl apply或kubectl replace将不会重新启动Pod，因此不会触发提取最新的image。标记它意味着一个复杂的脚本，该脚本总是删除旧的标记图像（无用的人在这里有窍门）。

kubectl rolling-update ... --image ...如果每个吊舱只有一个容器，则可以这样做。

可行的方法，最终是干净的方法，总是最新的方法是删除名称空间并重新创建所有pods / rc / services ...

即使每个Pod有多个容器，我如何要求Kubernetes很好地使用我的新映像？

Answer 1

肮脏的解决方法（未测试）：您可以将 rc 缩小到 0，然后放大到原始大小 => 它将是“pod”重新启动。或者您可以使用 2 个主动（非 0 大小）/被动（大小 0）rc，它们将包含在同一服务中。您将按比例放大/缩小它们。

标记它意味着一个复杂的脚本总是删除旧的标记图像（没用的人在这里有一个技巧）。

标记是很好的显式过程。Kubernetes 垃圾收集将自动删除您的旧图像。希望您知道，如果您只使用最新的标签，那么回滚是不可能的。我建议设置标签系统，例如:latest_stable, :latest_dev, :2nd_latest_stable, ...。

这些标签只是“指针”，您的 CI 将移动它们。然后您可以定义和编写一些智能注册表删除标记策略，例如所有早于2nd_latest stable可以安全删除的标记。您了解您的应用程序，因此您可以设置适合您的需求和发布政策的政策。

标签示例 - 起点构建 1/2/3（构建 id，git id，构建时间，...） - 构建 1 是:productionand :canary，所有标签都被推送：

# docker images
REPOSITORY                                  TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
image                                       3                   a21348af4283        37 seconds ago      125.1 MB
image                                       2                   7dda7c549d2d        50 seconds ago      125.1 MB
image                                       production          e53856d910b8        58 seconds ago      125.1 MB
image                                       canary              e53856d910b8        58 seconds ago      125.1 MB
image                                       1                   e53856d910b8        58 seconds ago      125.1 MB

构建 2 将是:canary：

# docker tag -f image:2 image:canary
# docker push image:canary
# docker images
REPOSITORY                                  TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
image                                       3                   a21348af4283        6 minutes ago       125.1 MB
image                                       canary              7dda7c549d2d        6 minutes ago       125.1 MB
image                                       2                   7dda7c549d2d        6 minutes ago       125.1 MB
image                                       production          e53856d910b8        7 minutes ago       125.1 MB
image                                       1                   e53856d910b8        7 minutes ago       125.1 MB

测试 OK，构建 2 是稳定的——它将是:production：

# docker tag -f image:2 image:production
# docker push image:production
# docker images
REPOSITORY                                  TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
image                                       3                   a21348af4283        9 minutes ago       125.1 MB
image                                       2                   7dda7c549d2d        9 minutes ago       125.1 MB
image                                       canary              7dda7c549d2d        9 minutes ago       125.1 MB
image                                       production          7dda7c549d2d        9 minutes ago       125.1 MB
image                                       1                   e53856d910b8        10 minutes ago      125.1 MB

作业：实际上构建 2 不稳定 -> 设置:production为构建 1（回滚）和:canary构建 3（构建 3 中的测试修复）。如果您只使用:latest，则此回滚是不可能的

kubectl滚动更新/回滚将使用显式，:id并且您的清理脚本可以使用策略：所有早于:production可以删除的标签。

不幸的是，我没有 Kubernetes 部署的经验。