如何解决Kubernetes：盲目使用 RollingUpdate 安全吗？
亲爱的
我对 Kubernetes 非常陌生，我目前正在处理我的服务（traefik、prometheus 等）的更新过程。我想避免可能导致错误或崩溃的强制性实时更新。我习惯于控制哪些需要更新，哪些不需要。
到目前为止，我了解到 Kubernetes 为字段 spec.updateStrategy.type 提供了 2 个可能的值：
我很惊讶没有找到与 apt Debian 工具相同的步骤：当我使用 apt update; apt upgrade 时，我会得到一个将更新的列表，然后我选择我想要更新的内容。
当我来到 Kubernetes 时，我想象更新可以保持这种两步走的精神，比如：
没有 stable,unstable,testing 频道，如带有 docker 的 Linux 存储库，那么我无法区分测试更新和可信赖更新。我担心 RollingUpdate 会毫无区别地部署每个新映像。
这引出了我的主要问题：盲目信任 RollingUpdate 是否完全安全？
解决方法
信任 RollingUpdate StatefulSet update strategy 是安全的。但是，需要注意的是，这不是“自动更新”。
StatefulSet（以及 Deployment）有一个模板 Pod 规范，它有一个 image:。这往往会命名要运行的映像的相当具体的版本。通常，Kubernetes 会检查节点上是否已经存在具有该名称和标签的映像，如果是，则尝试在不更新的情况下运行它（参见 Updating images，其中讨论了 imagePullPolicy: 字段） .
例如，如果您的 StatefulSet 显示 image: prom/prometheus:2.26.0，则您的 Pod 将完全使用该版本的 Prometheus，而不会使用其他版本。如果你只说 image: prom/prometheus 不带标签（或带 ...:latest），那么每个节点将拉取 Pod 启动时碰巧是最新的任何版本，你可以很容易地结束-同步版本。
使用更新策略的地方就是您更改 image: prom/prometheus:2.27.0 时。 Pod 规范中的图像无法修改，因此需要删除并重新创建现有的 Pod。如果您有 updateStrategy: { type: RollingUpdate }（默认值），那么 StatefulSet 控制器将为您执行此操作，特别是按顺序删除和重新创建 pod。如果您将其设置为 OnDelete，那么您需要手动删除 Pod。
由于您作为管理员控制 image:，因此您可以准确选择正在使用的版本；不存在会自动更新的“稳定更新通道”。相应地，您可以在预生产环境中部署更新的 StatefulSet YAML 配置以进行测试，然后再将其推广到生产环境。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
