0

亲爱的，

我对 Kubernetes 很陌生，我目前正在处理我的服务（traefik、prometheus 等）的更新过程。我想避免可能导致错误或崩溃的强制性实时更新。我习惯于控制哪些需要更新，哪些不需要。

到目前为止，我了解到 Kubernetes 为该字段提供了spec.updateStrategy.type2 个可能的值：

  • RollingUpdate：永久自动更新
  • OnDelete: 手动删除 pod 后自动更新

我很惊讶没有找到与使用aptDebian 工具相同的步骤：当我使用 时apt update; apt upgrade，我会得到一个将要更新的列表，然后我选择我想要更新的内容。

当我来到 Kubernetes 时，我认为更新可以保持这种两步走的精神，比如：

  1. 执行命令将集群上部署的当前 docker 镜像与 repos 进行比较。此命令将打印每个图像的新现有版本。
  2. 执行另一个命令来选择要更新的内容。

没有stable, unstable,testing像带有 docker 的 Linux 存储库这样的频道，那么我无法区分测试更新和可信赖的更新。我担心RollingUpdate会毫无区别地部署每个新图像。

这导致了我的主要问题：盲目信任是否完全安全RollingUpdate？

4

1 回答 1

1

信任RollingUpdate StatefulSet 更新策略是安全的。但是，重要的是要注意这不是“自动更新”。

StatefulSet（以及 Deployment）有一个模板 Pod 规范，该规范具有image:. 这往往会命名一个相当具体的图像版本来运行。一般来说，Kubernetes 会检查节点上是否已经存在具有该名称和标签的图像，如果是，则尝试在不更新的情况下运行它（请参阅更新图像，其中讨论了该imagePullPolicy:字段）。

image: prom/prometheus:2.26.0因此，例如，如果您的 StatefulSet 说，您的 Pod 将完全使用该版本的 Prometheus，而不是其他版本。如果你只是说不image: prom/prometheus带标签（或带...:latest），那么每个节点都会拉取 Pod 启动时恰好是当前的任何版本，并且你很容易以不同步的版本结束。

那么，使用更新策略的地方就是您更改image: prom/prometheus:2.27.0. Pod spec 中的镜像是不能修改的，所以需要删除现有的 Pod 并重新创建。如果您有updateStrategy: { type: RollingUpdate }（默认），那么 StatefulSet 控制器将为您执行此操作，特别是按顺序删除和重新创建 pod。如果您将其设置为，OnDelete则需要手动删除 pod。

由于您作为管理员控制，image:因此您可以准确选择正在使用的版本；不存在会自动更新的“稳定更新通道”。相应地，您可以在预生产环境中部署更新后的 StatefulSet YAML 配置以进行测试，然后再将其推广到生产环境。

于 2021-04-26T18:14:08.603 回答