5

When issuing a helm upgrade on a running pod, my configmap is updated, but will the pod know about the configmap updated values automatically or is there another step that I need to take to inject new configmap values into the pod?

My overall goal is to avoid having to interact with the running pod such as a delete or restart / reinstall.

I've seen a lot of info about changing sha1sum and doing some workarounds, but my question is more basic - do pods automatically become aware of new configmap items?

---- UPDATE --- so what we ended up doing was:

helm upgrade -n release -f release/values.yaml --recreate-pods

although this terminates the existing pod, another one is instantly started upon issuing the command, meaning "near zero" downtime.

texasdave
  • 506
  • 1
  • 4
  • 12

3 Answers3

30

If your Helm chart creates a ConfigMap, and that ConfigMap is mounted as a volume into a pod, then when the ConfigMap updates, the container filesystem also updates. It's then up to the application to notice that the files have changed.

Tricks like setting a hash of the file contents as a pod annotation are specifically there to cause a Deployment to update in a way that will delete and recreate existing Pods. This is okay! Pods in Kubernetes are very disposable, and if you delete a Pod managed by a Deployment it will get automatically recreated. If your application only reads the ConfigMap contents at startup time (this is very typical) then you need to do something like this to cause the Pod to restart on its own (copied out of the linked documentation):

kind: Deployment
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
CharlesB
  • 86,532
  • 28
  • 194
  • 218
David Maze
  • 130,717
  • 29
  • 175
  • 215
  • do you see a possibility to use this work around in combination with the "--wait" flag of the helm upgrade command? how I see it, the recreation of the pod in this way does not count as part of the new release and the upgrade command does not wait for the pods to be running after the restart – alex Apr 20 '21 at 14:28
  • Changing the annotation value will cause the deployment controller to create new pods, in the same way changing the image would, and `helm upgrade --wait` should wait for it. – David Maze Apr 20 '21 at 15:06
  • I realized that the --wait flag does not work for OpenShift DeploymentConfigs, which I am using instead of Deployments - but thanks anyway – alex Apr 27 '21 at 08:01
10

No, pods do not automatically become aware of the contents of a config map change.

In the case of a helm upgrade, that’s why you need to use helm template syntax to add the config map file’s hash value to the pod (or pod template) metadata. This creates a link between the config and pod.

If you do that, the pod (or pod template) is updated even if only the config map is changed. Then, no manual intervention is required.

Paul Annetts
  • 9,554
  • 1
  • 27
  • 43
  • This is untrue. If a ConfigMap or Secret is mounted as a volume, the content in the running pod is eventually updated too. https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#mounted-configmaps-are-updated-automatically That said, whether or not your app will _notice_ the change is a different problem, but the updated ConfigMap/Secret value will be present. – Mr. Llama Oct 29 '21 at 20:15
1

Using helm:

spec:
  strategy:
    type: "Recreate"
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "dmi.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      {{- with .Values.podAnnotations }}
      annotations:
        {{- toYaml . | nindent 8 }}
      {{- end }}
      labels:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum | trunc 10}}

As long your configmap will change the pod will recreate cause the checksum will be changed. I did use the strategy: Recreate cause my solution does not need rolling-update. But this should work with rolling-update too.

Constantin Radulescu
  • 61
  • 1
  • 5