Skip to content

External controller that trigger Kubernetes Deployments on ConfigMap or Secret changes

Notifications You must be signed in to change notification settings


Folders and files

Last commit message
Last commit date

Latest commit



33 Commits

Repository files navigation

Travis Licensed under Apache License version 2.0 Docker Automated Build


This Kubernetes controller, when installed will let users to configure Secret or ConfigMap names on Deployments that should trigger a rollout of this Deployment when the data inside the Secret or ConfigMap change.



On Kubernetes, you can run the controller image:

$ kubectl run trigger-controller --generator=deployment/apps.v1beta1

On OpenShift, you have to grant the controller permissions to work properly:

# Create special project and role
$ oc new-project k8s-trigger-controller
$ oc create clusterrole trigger-controller --verb=get,list,update,watch --resource=secrets,configmaps,deployments
$ oc adm policy add-cluster-role-to-user trigger-controller system:serviceaccount:k8s-trigger-controller:default

$ kubectl run trigger-controller --generator=deployment/apps.v1beta1 -n k8s-trigger-controller


First create Deployment:

$ kubectl run sleeper --generator=deployment/apps.v1beta1 --command -- /bin/bash -c "sleep infinity"

Create Secret:

$ kubectl create secret generic top-secret --from-literal=foo=bar

Add the Secret into Deployment as a volume (in Kubernetes, edit the Deployment resource)

$ oc volume deployment/sleeper --add --secret-name=top-secret -m /secret

Now, once the trigger controller is running, you can annotate the Deployment to indicate that you want to automatically rollout when the top-secret Secret is changed:

$ kubectl annotate deployment/sleeper'top-secret'

You can specify multiple Secrets separated by comma. For ConfigMaps, just use '-configMaps' in the annotation.

Now, when you change the content of the Secret top-secret (kubectl edit secret/top-secret) and change the value of the 'foo' key and save, you should see that a new rollout is triggered automatically.

How it works

When the controller observe Deployment with annotation, it will automatically calculate hash of the Secret 'data' field and store it inside the Secret annotation.

The it look up the Deployment and check if the ReplicaSet template embedded inside Deployment contain the[secret|configMap]-NAME-last-hash annotation. This annotation value represents the last observed hash. If the hash differs or the annotation is not present, the controller update the template with the current Secret or ConfigMap hash. Updating the Deployment template will cause the Deployment to rollout new version.

Limitations && TODO

  • Currently only Deployments are supported, StatefulSets and DaemonSets is TBD
  • If secrets or configMaps are updated in bulk, the controller might trigger rollout for every update (you should pause the Deployment in that case)
  • The hash calculation should be more efficient
  • Versioning of ConfigMaps and Secrets is out of scope for this controller


k8s-trigger-controller is licensed under the Apache License, Version 2.0.


External controller that trigger Kubernetes Deployments on ConfigMap or Secret changes







No releases published


No packages published