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

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

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

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

目前这个问题的最佳解决方案(在兄弟回答的https://github.com/kubernetes/kubernetes/issues/22368链接中有深入引用)是使用部署，并将configmap视为不可变的。

当您想要更改配置时，请创建一个带有您想要进行更改的新ConfigMap，并将部署指向新的ConfigMap。如果新的配置被破坏，部署将拒绝缩小您的工作ReplicaSet。如果新的配置有效，那么旧的ReplicaSet将被缩放为0副本并删除，新的pod将使用新的配置启动。

虽然没有编辑ConfigMap那么快，但是更安全。

Helm 3文档页

通常情况下，配置映射或秘密作为配置文件注入到容器中。根据应用程序的不同，如果后续的头盔升级更新了这些配置，则可能需要重新启动，但如果部署规范本身没有更改，则应用程序将继续使用旧配置运行，从而导致部署不一致。

sha256sum函数可以与include函数一起使用，以确保在其他规范更改时更新部署模板部分:

kind: Deployment
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/secret.yaml") . | sha256sum }}
[...]

在我的例子中，由于某些原因，$. template。BasePath没有工作，但$. chart。名称:

spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: admin-app
      annotations:
        checksum/config: {{ include (print $.Chart.Name "/templates/" $.Chart.Name "-configmap.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，如果它最终能够工作的话。

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

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

例如:

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

我发现最好的方法是运行Reloader

它允许您定义要监视的配置映射或秘密，当它们更新时，将执行部署的滚动更新。这里有一个例子:

你有一个部署foo和一个名为foo- ConfigMap的ConfigMap。您希望在每次更改configmap时滚动部署的pod。你需要运行Reloader:

kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml

然后在部署中指定这个注释:

kind: Deployment
metadata:
  annotations:
    configmap.reloader.stakater.com/reload: "foo-configmap"
  name: foo
...

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

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

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

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

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

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

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

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

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

如果k8 > 1.15;然后做一个rollout重启对我来说是最好的，作为CI/CD的一部分，应用配置路径与卷挂载相连。重新加载插件或设置restartPolicy: Always in deployment manifest YML对我不起作用。不需要更改应用程序代码，既适用于静态资产，也适用于微服务。

kubectl rollout restart deployment/<deploymentName> -n <namespace> 

考虑使用kustomize(或kubectl apply -k)，然后利用它强大的configMapGenerator特性。例如，来自:https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/configmapgenerator/

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

# Just one example of many...
- name: my-app-config
  literals:
  - JAVA_HOME=/opt/java/jdk
  - JAVA_TOOL_OPTIONS=-agentlib:hprof

  # Explanation below...
  - SECRETS_VERSION=1

然后在部署中引用my-app-config即可。当使用kustomize构建时，它会自动查找并更新my-app-config的引用，并使用更新的后缀，例如my-app-config-f7mm6mhf59。

额外的好处是，更新秘密:我还使用此技术强制重新加载秘密(因为它们以同样的方式受到影响)。虽然我个人完全单独管理我的秘密(使用Mozilla sops)，但您可以将配置映射与您的秘密捆绑在一起，例如在您的部署中:

# ...
spec:
  template:
    spec:
      containers:
        - name: my-app
          image: my-app:tag
          envFrom:
            # For any NON-secret environment variables. Name is automatically updated by Kustomize
            - configMapRef:
                name: my-app-config

            # Defined separately OUTSIDE of Kustomize. Just modify SECRETS_VERSION=[number] in the my-app-config ConfigMap
            # to trigger an update in both the config as well as the secrets (since the pod will get restarted).
            - secretRef:
                name: my-app-secrets

然后，像我上面所做的那样，在ConfigMap中添加一个像SECRETS_VERSION这样的变量。然后，每次更改my-app-secrets时，只需增加SECRETS_VERSION的值，这除了触发kustomize'd ConfigMap名称的更改外，没有其他用途，这也应该导致重新启动pod。然后就变成:

如何自动重启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