when doing a deployment with helm, it stores release histories in config maps in the kube-system namespace.
these releases have names like “my_groovy_release.v34” or whatever.
when doing a helm init, there is an option called –history-max which allows you to tell tiller, how many of these config maps to keep.
we didn’t know we had to set this, and we had 300+ of these release versioned config maps.
at some point, for tiller to load them all, it crashed because OOM.
so we fixed it with:
helm init --upgrade --history-max=50
on the next deployment with helm, the deployed release will have its config maps adjusted down to the number you set it to.