We would like to watch if some change happens in ConfigMap and/or Secret; then perform a rolling upgrade on relevant DeploymentConfig, Deployment, Daemonset, Statefulset and Rollout
Reloader can watch changes in ConfigMap and Secret and do rolling upgrades on Pods with their associated DeploymentConfigs, Deployments, Daemonsets Statefulsets and Rollouts.
Reloader is available in two different versions:
- Open Source Version
- Enterprise Version, which includes:
- SLA (Service Level Agreement) for support and unique requests
- Slack support
- Certified images
Contact sales@stakater.com for info about Reloader Enterprise.
Reloader is compatible with Kubernetes >= 1.19
For a Deployment called foo have a ConfigMap called foo-configmap or Secret called foo-secret or both. Then add your annotation (by default reloader.stakater.com/auto) to main metadata of your Deployment
kind: Deployment
metadata:
annotations:
reloader.stakater.com/auto: "true"
spec:
template:
metadata:This will discover deploymentconfigs/deployments/daemonsets/statefulset/rollouts automatically where foo-configmap or foo-secret is being used either via environment variable or from volume mount. And it will perform rolling upgrade on related pods when foo-configmap or foo-secretare updated.
You can restrict this discovery to only ConfigMap or Secret objects that
are tagged with a special annotation. To take advantage of that, annotate
your deploymentconfigs/deployments/daemonsets/statefulset/rollouts like this:
kind: Deployment
metadata:
annotations:
reloader.stakater.com/search: "true"
spec:
template:and Reloader will trigger the rolling upgrade upon modification of any
ConfigMap or Secret annotated like this:
kind: ConfigMap
metadata:
annotations:
reloader.stakater.com/match: "true"
data:
key: valueprovided the secret/configmap is being used in an environment variable, or a volume mount.
Please note that reloader.stakater.com/search and
reloader.stakater.com/auto do not work together. If you have the
reloader.stakater.com/auto: "true" annotation on your deployment, then it
will always restart upon a change in configmaps or secrets it uses, regardless
of whether they have the reloader.stakater.com/match: "true" annotation or
not.
We can also specify a specific configmap or secret which would trigger rolling upgrade only upon change in our specified configmap or secret, this way, it will not trigger rolling upgrade upon changes in all configmaps or secrets used in a deploymentconfig, deployment, daemonset, statefulset or rollout.
To do this either set the auto annotation to "false" (reloader.stakater.com/auto: "false") or remove it altogether, and use annotations for Configmap or Secret.
It's also possible to enable auto reloading for all resources, by setting the --auto-reload-all flag.
In this case, all resources that do not have the auto annotation set to "false", will be reloaded automatically when their ConfigMaps or Secrets are updated.
Notice that setting the auto annotation to an undefined value counts as false as-well.
To perform rolling upgrade when change happens only on specific configmaps use below annotation.
For a Deployment called foo have a ConfigMap called foo-configmap. Then add this annotation to main metadata of your Deployment
kind: Deployment
metadata:
annotations:
configmap.reloader.stakater.com/reload: "foo-configmap"
spec:
template:
metadata:Use comma separated list to define multiple configmaps.
kind: Deployment
metadata:
annotations:
configmap.reloader.stakater.com/reload: "foo-configmap,bar-configmap,baz-configmap"
spec:
template:
metadata:To perform rolling upgrade when change happens only on specific secrets use below annotation.
For a Deployment called foo have a Secret called foo-secret. Then add this annotation to main metadata of your Deployment
kind: Deployment
metadata:
annotations:
secret.reloader.stakater.com/reload: "foo-secret"
spec:
template:
metadata:Use comma separated list to define multiple secrets.
kind: Deployment
metadata:
annotations:
secret.reloader.stakater.com/reload: "foo-secret,bar-secret,baz-secret"
spec:
template:
metadata:- Reloader also supports sealed-secrets. Here are the steps to use sealed-secrets with Reloader.
- For
rolloutsReloader simply triggers a change is up to you how you configure therolloutstrategy. reloader.stakater.com/auto: "true"will only reload the pod, if the configmap or secret is used (as a volume mount or as an env) inDeploymentConfigs/Deployment/Daemonsets/Statefulsetssecret.reloader.stakater.com/reloadorconfigmap.reloader.stakater.com/reloadannotation will reload the pod upon changes in specified configmap or secret, irrespective of the usage of configmap or secret.- you may override the auto annotation with the
--auto-annotationflag - you may override the search annotation with the
--auto-search-annotationflag and the match annotation with the--search-match-annotationflag - you may override the configmap annotation with the
--configmap-annotationflag - you may override the secret annotation with the
--secret-annotationflag - you may want to prevent watching certain namespaces with the
--namespaces-to-ignoreflag - you may want to watch only a set of namespaces with certain labels by using the
--namespace-selectorflag - you may want to watch only a set of secrets/configmaps with certain labels by using the
--resource-label-selectorflag - you may want to prevent watching certain resources with the
--resources-to-ignoreflag - you can configure logging in JSON format with the
--log-format=jsonoption - you can configure the "reload strategy" with the
--reload-strategy=<strategy-name>option (details below)
Reloader supports multiple "reload" strategies for performing rolling upgrades to resources. The following list describes them:
- env-vars: When a tracked
configMap/secretis updated, this strategy attaches a Reloader specific environment variable to any containers referencing the changedconfigMaporsecreton the owning resource (e.g.,Deployment,StatefulSet, etc.). This strategy can be specified with the--reload-strategy=env-varsargument. Note: This is the default reload strategy. - annotations: When a tracked
configMap/secretis updated, this strategy attaches areloader.stakater.com/last-reloaded-frompod template annotation on the owning resource (e.g.,Deployment,StatefulSet, etc.). This strategy is useful when using resource syncing tools like ArgoCD, since it will not cause these tools to detect configuration drift after a resource is reloaded. Note: Since the attached pod template annotation only tracks the last reload source, this strategy will reload any tracked resource should itsconfigMaporsecretbe deleted and recreated. This strategy can be specified with the--reload-strategy=annotationsargument.
You can deploy Reloader by following methods:
You can apply vanilla manifests by changing RELEASE-NAME placeholder provided in manifest with a proper value and apply it by running the command given below:
kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yamlBy default, Reloader gets deployed in default namespace and watches changes secrets and configmaps in all namespaces.
Reloader can be configured to ignore the resources secrets and configmaps by passing the following arguments (spec.template.spec.containers.args) to its container :
| Argument | Description |
|---|---|
| --resources-to-ignore=configMaps | To ignore configMaps |
| --resources-to-ignore=secrets | To ignore secrets |
Note: At one time only one of these resource can be ignored, trying to do it will cause error in Reloader. Workaround for ignoring both resources is by scaling down the Reloader pods to 0.
Reloader can be configured to only watch secrets/configmaps with one or more labels using the --resource-label-selector parameter. Supported operators are !, in, notin, ==, =, !=, if no operator is found the 'exists' operator is inferred (i.e. key only). Additional examples of these selectors can be found in the Kubernetes Docs.
Note: The old : delimited key value mappings are deprecated and if provided will be translated to key=value. Likewise, if a wildcard value is provided (e.g. key:*) it will be translated to the standalone key which checks for key existence.
These selectors can be combined together, for example with:
--resource-label-selector=reloader=enabled,key-exists,another-label in (value1,value2,value3)Only configmaps or secrets labeled like the following will be watched:
kind: ConfigMap
apiVersion: v1
metadata:
...
labels:
reloader: enabled
key-exists: yes
another-label: value1
...Reloader can be configured to only watch namespaces labeled with one or more labels using the --namespace-selector parameter. Supported operators are !, in, notin, ==, =, !=, if no operator is found the 'exists' operator is inferred (i.e. key only). Additional examples of these selectors can be found in the Kubernetes Docs.
Note: The old : delimited key value mappings are deprecated and if provided will be translated to key=value. Likewise, if a wildcard value is provided (e.g. key:*) it will be translated to the standalone key which checks for key existence.
These selectors can be combined together, for example with:
--namespace-selector=reloader=enabled,test=true
