0

I frequently have this problem when doing Kubernetes or OpenShift deployments (with or without helm, but in this question I'd like to focus on a solution involving helm):

Most of our microservices have some configmap(s) or secret(s). The name of the maps/secrets and the expected keys are, in my mind, part of the microservice - i.e., should be in the source repository of the microservice, together with the other kubernetes-related yAML files (in this case: a helm chart for this microservice). The configmap.yaml will contain empty values (or useful default values) for all keys.

During initial deployment via our CI/CD pipeline (i.e., at the end of the day, helm install), there is no problem. The configmap/secret will be created same as the other objects. The proper, actual values can then be provided in some other manner, either manually for small enough environments or through some other part of the pipeline; these values are usually different for each deployment environment, so cannot really be a part of the code repository that ships with the microservice. Especially the secrets of course cannot go into any CVS.

But in subsequent deployments, running the helm update will simply overwrite any configs with the empty or default values, breaking everything. On the other hand, we cannot simply skip the configmaps completely during an upgrade, as we want to add newly created keys to them.

In my projects, we usually end up with some small custom script which separates the configmaps/secrets from the other kubernetes objects, and uses kubectl to check for the existence of individual keys in the configmap, only adding those that are missing.

Is there any idiom in helm to make this easy and elegant to work with? Preferably without adding a completely new tool to the stack. At the moment we have relatively few services and environments; I am fine with starting in a KISS manner and only upgrading to something else if and when it should ever get out of hand.

I did find several questions/answers which vaguely go in this direction, but they are more about how to structure helm charts in a microservice architecture - this is not the question so much here. The bigger picture in my current use case is that there will be a chart per microservice (stored in the microservice repo and added to the helm repo through the pipeline), and probably a separate git repo / helm chart per environment which just pulls in the correct microservice charts. I don't think the information about the configmap/secret keys should go into that central "environment chart" either, really.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.