Context
Alongside the deployment of containers, we often ship configuration via ConfigMap and/or Secret resources. A common challenge is the need to restart the Pod resources when there is a change in the associated configuration.
By default, if the application itself didn’t change (e.g with a new container version), then the Pod spec may not change and thus, the Deployment or StatefulSet resource will not trigger a new rollout.
Rolling options
We have several options to automate the rolling of Pods based on configuration
Always roll the Pod
It doesn’t matter if there was an actual configuration change or not, this will always roll the pods over when a new release happens in Kubernetes
kind: <ResourceKind> # Deployment, StatefulSet, etc
spec:
template:
metadata:
annotations:
rollme: {{ randAlphaNum 5 | quote }}
Roll when Secret or ConfigMap resources changes
For resources, defined in the helm chart:
kind: <ResourceKind> # Deployment, StatefulSet, etc
spec:
template:
metadata:
annotations:
checksum/config: {{ include (print $.Template.BasePath "/<filename>.yaml") . | sha256sum }}
For resources defined as part of a library chart:
kind: <ResourceKind> # Deployment, StatefulSet, etc
spec:
template:
metadata:
annotations:
checksum/config: {{ include ("mylibchart.configmap") . | sha256sum }}
Roll when external resources changes
One option is reloader, which leverages specific annotations in the resources to force them to roll based on changes to Secret/ConfigMap resources.