考虑使用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。然后就变成:

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 }}

我发现最好的方法是运行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
...

考虑使用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。然后就变成:

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

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

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

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