Skip to content

Latest commit

 

History

History
12 lines (9 loc) · 3.79 KB

Reloader-vs-ConfigmapController.md

File metadata and controls

12 lines (9 loc) · 3.79 KB

Reloader vs ConfigmapController

Reloader is inspired from Configmapcontroller but there are many ways in which it differs from configmapController. Below is the small comparison between these two controllers.

Reloader Configmap
Reloader can watch both secrets and configmaps. ConfigmapController can only watch changes in configmaps. It cannot detect changes in other resources like secrets.
Reloader can perform rolling upgrades on deployments as well as on statefulsets and daemonsets ConfigmapController can only perform rolling upgrades on deployments. It currently does not support rolling upgrades on statefulsets and daemonsets
Reloader provides both unit test cases and end to end integration test cases for future updates. So one can make sure that new changes do not break any old functionality. Currently there are not any unit test cases or end to end integration test cases in configmap controller. It add difficulties for any additional updates in configmap controller and one can not know for sure whether new changes breaks any old functionality or not.
Reloader uses SHA1 to encode the change in configmap or secret. It then saves the SHA1 value in STAKATER_FOO_CONFIGMAP or STAKATER_FOO_SECRET environment variable depending upon where the change has happened. The use of SHA1 provides a concise 40 characters encoded value that is very less pron to collision. Configmap controller uses FABRICB_FOO_REVISION environment variable to store any change in configmap controller. It does not encode it or convert it in suitable hash value to avoid data pollution in deployment.
Reloader allows you to customize your own annotation (for both Secrets and Configmaps) using command line flags Configmap controller restricts you to only their provided annotation