时间戳

首页 > 解决方案 > 有状态集的 RollingUpdate 不会重新启动 pod，并且来自更新的 ConfigMap 的更改不会反映

prometheus - 有状态集的 RollingUpdate 不会重新启动 pod，并且来自更新的 ConfigMap 的更改不会反映

问题描述

我正在使用 Prometheus 和 Prometheus Alertmanager 发送警报。

我已经在 GKE 上运行了 Kubernetes 状态集。我更新了 Prometheus 和 Prometheus AlertManager 的 ConfigMap，并对有状态集进行了 RollingUpdate，但是 pod 没有重新启动，而且它似乎仍在使用旧的 ConfigMap。

我使用了更新 ConfigMaps 的命令

kubectl create configmap prometheus-alertmanager-config --from-file alertmanager.yml -n mynamespace -o yaml --dry-run | kubectl replace -f - 同样，我也为 Prometheus 进行了更新。

对于 RollingUpdate，我使用了以下命令：

kubectl patch statefulset prometheus-alertmanager -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}' -n mynamespace

另外，当我做 rollingUpdate 它显示

statefulset.apps/prometheus-alertmanager patched (no change)

我不知道发生了什么，是否无法通过 RollingUpdate 使有状态集中的 pod 适应更新的 ConfigMap？或者我在这里遗漏了什么？

标签： prometheusprometheus-alertmanagerconfigmapkubernetes-statefulset

解决方案

必须重新启动 Prometheus pod 才能获取更新的 ConfigMap 或 Secret。

滚动更新不会总是重新启动 Pod（仅当 Pod 的直接配置属性发生更改时。例如 - 图像标签。）

kubectl v1.15 现在提供了一个 rollout restart 子命令，允许您在 Deployment 中重新启动 Pod - 考虑到您的浪涌/不可用性配置 - 从而让它们获取对引用的 ConfigMap、Secret 或类似内容的更改。值得注意的是，您可以在 v1.15 之前的集群中使用它，因为它是在客户端中实现的。

用法示例：kubectl rollout restart deployment/prometheus 重新启动特定部署。就这么简单！

更多信息 -在这里。

推荐阅读