我也在这个问题上思考了一段时间，希望以一种优雅而快速的方式解决这个问题。

以下是我的20美分:

如果您正在更新标签，这里提到的使用标签的答案将不起作用。但如果你总是添加标签的话就可以了。详情请点击这里。 这里提到的答案是最优雅的方式来快速做到这一点，根据我，但有处理删除的问题。我在这个答案的基础上补充说:

解决方案

我在一个Kubernetes操作符中这样做，在一个调和循环中只执行一个任务。

Compute the hash of the config map data. Say it comes as v2. Create ConfigMap cm-v2 having labels: version: v2 and product: prime if it does not exist and RETURN. If it exists GO BELOW. Find all the Deployments which have the label product: prime but do not have version: v2, If such deployments are found, DELETE them and RETURN. ELSE GO BELOW. Delete all ConfigMap which has the label product: prime but does not have version: v2 ELSE GO BELOW. Create Deployment deployment-v2 with labels product: prime and version: v2 and having config map attached as cm-v2 and RETURN, ELSE Do nothing.

就是这样!它看起来很长，但这可能是最快的实现，并且原则上将基础设施视为牛(不可变性)。

此外，当您的Kubernetes部署有rebuild更新策略时，上述解决方案也可以工作。在其他情况下，逻辑可能需要稍作调整。

如何自动重启Kubernetes pod和相关的pod 当他们的configmap改变/更新部署?

如果您使用configmap作为环境，则必须使用外部选项。

复载机 Kube观察家 配置器

Kubernetes自动重新加载配置映射，如果它被挂载为卷(如果子路径在那里，它不会工作)。

When a ConfigMap currently consumed in a volume is updated, projected keys are eventually updated as well. The kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, the kubelet uses its local cache for getting the current value of the ConfigMap. The type of the cache is configurable using the ConfigMapAndSecretChangeDetectionStrategy field in the KubeletConfiguration struct. A ConfigMap can be either propagated by watch (default), ttl-based, or by redirecting all requests directly to the API server. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the Pod can be as long as the kubelet sync period + cache propagation delay, where the cache propagation delay depends on the chosen cache type (it equals to watch propagation delay, ttl of cache, or zero correspondingly).

正式文档:https://kubernetes.io/docs/concepts/configuration/configmap/#mounted-configmaps-are-updated-automatically

作为环境变量使用的configmap不会自动更新，并且需要pod重新启动。

简单示例

apiVersion: v1
kind: ConfigMap
metadata:
  name: config
  namespace: default
data:
  foo: bar

舱配置

spec:
  containers:
  - name: configmaptestapp
    image: <Image>
    volumeMounts:
    - mountPath: /config
      name: configmap-data-volume
    ports:
    - containerPort: 8080
  volumes:
    - name: configmap-data-volume
      configMap:
        name: config

例如:https://medium.com/@harsh.manvar111/update-configmap- with-restart -pod-56801dce3388

当部署在子图表中，而控制它的值在父图表的值文件中时，出现了这个问题。这是我们用来触发重启的:

spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ tpl (toYaml .Values) . | sha256sum }}

显然，这将在任何值更改时触发重新启动，但它适用于我们的情况。最初在子图中的内容只有在配置。Yaml在子图中本身发生了变化:

    checksum/config: {{ include (print $.Template.BasePath "/config.yaml") . | sha256sum }}

在配置映射更新时向pod发送信号是一个正在工作的功能(https://github.com/kubernetes/kubernetes/issues/22368)。

你总是可以写一个自定义的pid1来通知confimap已经改变并重新启动你的应用程序。

您还可以例如:在两个容器中挂载相同的配置映射，在第二个容器中暴露一个http健康检查，如果配置映射内容的哈希值发生变化，该检查将失败，并将其作为第一个容器的活动探测(因为pod中的容器共享相同的网络名称空间)。当探测失败时，kubelet将为您重新启动第一个容器。

当然，如果您不关心pod在哪些节点上，您可以简单地删除它们，复制控制器将为您“重新启动”它们。

另一种方法是将其插入部署的命令部分:

...
command: [ "echo", "
  option = value\n
  other_option = value\n
" ]
...

或者，为了使它更像configmap，使用一个额外的部署，它只会在命令节中托管该配置，并在其上执行kubectl create，同时在其名称中添加一个唯一的“版本”(比如计算内容的哈希值)，并修改所有使用该配置的部署:

...
command: [ "/usr/sbin/kubectl-apply-config.sh", "
  option = value\n
  other_option = value\n
" ]
...

我可能会发布kubectl-apply-config.sh，如果它最终能够工作的话。

(不要那样做;看起来太糟糕了)

您可以更新与您的部署无关的元数据注释。它将触发滚动更新

例如:

    spec:
      template:
        metadata:
          annotations:
            configmap-version: 1