Skip to content

Helm, Kubernetes, and the immutable configMap… a design pattern

Lets say you have got some program that doesn’t reload when its config changes. You introduce it to Kubernetes via helm. You use a configMap. All is good. Later you do a helm upgrade and… nothing happens. You are sad. You roll up your sleeves, write some code using inotify(), and the program restarts as soon as a change happens to the config. You are happy. Until that day you make a small typo in the config, call helm upgrade, and watch the continuous suicide of your Pods. Now you are sad again. If only there were a better way.

I present to you the better way. And its simple. It solves both problems at once.

Conceptually its pretty simple. You make the ‘name’ of the configMap have its contents-hash in it. Now, when it changes, the Deployment is different, so it will start to replace the Pods. It will ripple through, as the new Pods start, they must come online before the old ones will die. Thus if you have an error, it will not be a problem. Boom!

So here’s a subset of an example:. You’re welcome.

apiVersion: v1
kind: ConfigMap
  name: {{ include "X.fullname" . }}-\
        {{ tpl .Values.config . | sha256sum | trunc 8 }}-\
        {{ tpl .Values.application . | sha256sum | trunc 8 }}-\
        {{ tpl .Values.logging . | sha256sum | trunc 8 }}
  labels: {{ include "" . }} {{ include "X.chart" . }} {{ .Release.Name }} {{ .Release.Service }}
  server.json: {{ tpl .Values.config . | quote }}
  application.ini: {{ tpl .Values.application . | quote }}
  logback.xml: {{ tpl .Values.logging . | quote }}

apiVersion: apps/v1beta2
kind: Deployment
      - mountPath: /X/conf
        name: {{ include "X.fullname" . }}-config
    - name: {{ include "X.fullname" . }}-config
        name: {{ include "X.fullname" . }}-\
              {{ tpl .Values.config . | sha256sum | trunc 8 }}-\
              {{ tpl .Values.application . | sha256sum | trunc 8 }}-\
              {{ tpl .Values.logging . | sha256sum | trunc 8 }}

2 thoughts on “Helm, Kubernetes, and the immutable configMap… a design pattern”

  1. Immutable config map is very good and safe solution, but there is one problem. If config map is generated from parts it’s nice to have diff between old and new one, but in your solution they are different objects and helm diff plugin display it one above the other. Comparing them can be difficult especially when content is long.

    1. for sure. since i wrote this, we have switched to kustomize for everything. it also follows the immutable configmap pattern, and makes the kubectl diff harder to use.

Leave a Reply

Your email address will not be published. Required fields are marked *