search

stakater / Reloader

A Kubernetes controller to watch changes in ConfigMap and Secrets and do rolling upgrades on Pods with their associated Deployment, StatefulSet, DaemonSet and DeploymentConfig – [✩Star] if you're using it!
https://docs.stakater.com/reloader/
Apache License 2.0
7.47k stars 498 forks source link

Question: how do I decide between auto, reload, and search/match? #663

Open aqeelat opened 4 months ago

aqeelat commented 4 months ago

I have a bunch of helm charts deployments, most with their own configmap/secret. I also have a couple of shared secrets and configmaps.

The current configmaps and secrets have the same name as the deployment.

My options:

  1. auto. I will have to rename everything which is fine, but this will not cover the shared stuff, and will not cover envFrom.
  2. reload. I could also use some jujitsu templating (or statically) and add the names of all configmaps/secrets used in each deployment.
  3. search/match. I could also slap search/match on everything and call it a day.

In my situation, the first option does not seem like a good idea. The third option is very appealing, but are there performance implications? If the third option is out, then reload will be the winning option.

SheryarButt commented 4 months ago

Hi @aqeelat Have you tried the first approach? And why do you have to rename everything?

bnallapeta commented 3 months ago

@aqeelat let us know if you need any further help from our end on this.

h-mavrodiev commented 3 months ago

Hi @SheryarButt , I am in a similar situation as @aqeelat. From the Reloader documentation it seems like if you go for the first approach it does the config map/ secret discovery by name -> if your deployment is called FOO, it reads from the docs that you NEED secret/confMap named FOO for the Reloader to work. If that's the case, if your config maps and secrets are not named as the Reloaded expects them to be, you would need to rename everything in order to use the first approach. It also would not work if different Deployments are sharing secrets or config map. In that situation, it seems that the only option would be to use approach 2.

Is that so, or does the discovering of which secret/confMaps is used by a Deployment works differently?

SheryarButt commented 3 months ago

Hi @h-mavrodiev The documentation doesn't say that you NEED to have the secret/config map named FOO, it's just an example to make things easier for beginners. We'll update the docs to resolve this ambiguity as well.

For the actual solution, no you don't have to name the secret/config map to be the same as the deployment.