如何很好地要求 Kubernetes 检索更新的图像？答案

【问题标题】：How to ask Kubernetes nicely to retrieve newer image?如何很好地要求 Kubernetes 检索更新的图像？
【发布时间】：2016-06-02 10:55:34
【问题描述】：

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

如果标签为 :latest 或 imagePullPolicy: Always，Kubernetes Pods 将在重新启动时检索最新的镜像。

但是，除非图像标签发生更改，否则执行 kubectl apply 或 kubectl replace 不会重新启动 Pod，因此不会触发拉取最新图像。标记它意味着一个复杂的脚本总是删除旧标记的图像（没用的人在这里有技巧）。

如果每个 pod 仅有一个容器，则可以使用 kubectl rolling-update ... --image ...。

有效且最终干净且始终获取最新的方法是删除命名空间并重新创建所有 pods/rc/services...

即使每个 Pod 有多个容器，我如何才能让 Kubernetes 很好地使用我的新镜像？

【问题讨论】：

标签： kubernetes google-kubernetes-engine google-container-registry

【解决方案1】：

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

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

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

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

标签示例 - 起点构建 1/2/3（构建 id、git id、构建时间……） - 构建 1 是 :production 和 :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

Build 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

测试正常，构建 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 部署经验。

【讨论】：

GC 可能适用于集群，但不会自动清理 Docker Registry。假设我使用 git commit 的哈希作为标签（IMO 最简单），它也会保留所有以前的提交。
感谢您的更新。您是否有一个更完整的示例来进行完整的部署和重新标记？比如推送新的:canary，然后替换之前的:production，包括Docker推送？我认为新的实验部署应该自动允许这些，但它还没有发布。
我确实知道如何推送图像，但是从我看到的情况来看，我需要有多个具有不同标签的 kubernetes.yml 并首先进行滚动更新，然后我猜在重新标记后，执行 kubectl apply或类似的，但这是我不确定的部分。此外，据我所知，注册表不支持从现有标签远程添加标签，因此每次构建需要另外 20 秒的开销，等等。
@jan-garaj 你的回答有很多有趣的想法和一些有用的建议，但是看到 sn-p 以“作业：...”开头令人不快，因为它看起来像 ura 老师和你把作业交给你的学生。据我所知，这不是 StackOverflow 上的正确行为，因为这是一个回答问题而不是提供教学和作业的地方。如果我理解错误，我很抱歉。另一个问题是你说你没有 k8s 部署经验的终点线：那你为什么要对 k8s 部署提出建议呢？ o_O

【解决方案2】：

如何使用标签标记部署，该标签的值是时间戳或提交哈希，然后像往常一样使用kubectl apply。更改模板中的标签应该会再次触发拉取图像（如果设置了imagePullPolicy: Always）和滚动升级（取决于配置）。

【讨论】：