Dears，
我是Kubernetes的新手，目前正在处理我的服务(traefik，prometheus，…(的更新过程。我想避免强制性的实时更新，这可能会导致错误或崩溃。我习惯于控制哪些需要更新，哪些不需要更新。
到目前为止，我了解到Kubernetes为字段spec.updateStrategy.type提供了两个可能的值：
RollingUpdate：永久自动更新OnDelete：手动删除吊舱后自动更新
我很惊讶没有发现与aptDebian工具相同的步骤：当我使用apt update; apt upgrade时，我会得到一个将要更新的内容的列表，并选择我想要更新的内容。
当我来到Kubernetes时，我认为更新将允许保持这两步精神，比如：
- 执行一个命令，将部署在集群上的当前docker映像与repo进行比较。此命令将打印每个图像的新的现有版本
- 执行另一个命令以选择要更新的内容
没有像带有docker的Linux存储库那样的stable、unstable、testing通道，那么我无法区分测试更新和值得信赖的更新。我担心RollingUpdate会毫无区别地部署每个新映像。
这引出了我的主要问题：盲目信任RollingUpdate是否完全安全？
信任RollingUpdateStatefulSet更新策略是安全的。然而，重要的是要注意，这是而不是的"；"自动更新"；。
StatefulSet(以及Deployment(具有一个模板Pod规范，该规范具有一个image:。这往往会命名要运行的映像的一个相当特定的版本。通常，Kubernetes会检查节点上是否已经存在具有该名称和标记的映像，如果已经存在，则尝试在不更新映像的情况下运行该映像(请参阅updating images，其中讨论了imagePullPolicy:字段(。
因此，例如，如果你的StatefulSet说image: prom/prometheus:2.26.0，你的Pods将使用，而不是其他版本的普罗米修斯。如果你只说image: prom/prometheus没有标签(或者有...:latest(，那么每个节点都会在Pod启动时拉取任何版本的最新版本，你很容易就会得到不同步的版本。
那么，当您更改image: prom/prometheus:2.27.0时，就会使用更新策略。Pod规范中的图像无法修改，因此需要删除并重新创建现有的Pod。如果您有updateStrategy: { type: RollingUpdate }(默认值(，那么StatefulSet控制器将为您执行此操作，特别是按顺序删除和重新创建pod。如果将其设置为OnDelete，则需要手动删除pod。
由于您作为管理员控制image:，因此您可以准确地选择要使用的版本；不存在所谓的"；稳定更新信道"；将自动更新。相应地，您可以在预生产环境中部署更新的StatefulSet YAML配置，以便在将其升级到生产环境之前进行测试。