What is a typical strategy for deploying ConfigMap changes with app in Kubernetes without changing behaviour of existing app?

Question

I have an updated app to deploy to Kubernetes with a new image and modified config in a ConfigMap. The config might be an updated value, something removed or a completely new configuration key.

My question is, how should I isolate changes to the new version only and not apply config to any existing version?

I've read about immutable config maps, which suggests to me creating a new ConfigMap with each deploy, or with each config change, is a possible option. I'm unsure if they're intended to be used in this way. Or how best to remove the previous one safely once nothing else is using it.

Also, how do I guarantee the config is available before rolling update of the pods begins?

Answer 1

If every revision of you deployment you will apply some custom config then having this in separate/new ConfigMap is the right way to go.

You can consider deploying your application using helm chart which are simply yaml files combined into single package. It is easy to version them and share with other because once done right they goal is to be reusable. This means that common parts of the manifest can be changed in values without rewriting the templates. Helm has the native capability of rolling back a release to any previous revision.

Depending on your needs and use case, Kustomize has an option to generate a new ConfigMap or Secret called generatorOptions