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

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

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

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

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

...
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，如果它最终能够工作的话。

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

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

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

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

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

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

以下是我的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更新策略时，上述解决方案也可以工作。在其他情况下，逻辑可能需要稍作调整。

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

例如:

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

向配置映射添加不可变属性完全避免了这个问题。使用配置散列有助于无缝滚动更新，但对回滚没有帮助。你可以看看这个开源项目- 'Configurator' - https://github.com/gopaddle-io/configurator.git .'Configurator'通过以下使用自定义资源工作:

配置器将部署生命周期与configMap绑定在一起。当 配置映射被更新，并为此创建一个新版本 configMap。所有附加到configMap的部署 获得与最新configMap版本绑定的滚动更新。 当您将部署回滚到旧版本时，它会反弹到 configMap在滚动更新之前的版本。

通过这种方式，您可以维护配置映射的版本，并方便与配置映射一起滚转和回滚到部署。