In this blog post, “RELOADER for Kubernetes Rollouts” we are going to explore a highly useful tool that will allow us to make changes to our configurations and redeploy our Pods with those changes.

One of the most common tasks when we develop and deploy our applications in Kubernetes is making changes to our configurations, such as configmaps or secrets. These changes typically have an impact, or at least they should, on our deployments. However, many times we forget to redeploy the deployment, Pod, statefulset, etc., which means that the change is never applied.

Furthermore, when a change could affect multiple deployments, the situation becomes more complex, requiring manual changes or non-automated deployments.

Rollout for deploying applications due to changes

I’m sure you’ve encountered the problem of having to redeploy an application due to configuration changes more than once. One of the solutions I once implemented was the use of a sidecar.

The sidecar I implemented was responsible for checking if any changes had occurred in a configuration file (secret or configmap). If a change was detected, it would restart the corresponding pod(s). While this is a functional solution, if something already exists to solve the problem, why reinvent the wheel?

So, in order to avoid unnecessary work and reinventing something that already exists, I eventually discovered a more suitable solution—a Kubernetes tool designed for precisely that purpose, Reloader

Configuration with Reloader

Reloader is a Kubernetes tool that allows us to detect changes in our ConfigMaps or Secrets. You just need to configure it in your Kubernetes cluster and add an annotation to your deployment specifying the ConfigMap or Secret that it will affect.

Using Reloader is very straightforward and intuitive through annotations. Once it has been successfully installed in our cluster, we can start using it.

To make use of this tool, we will add the necessary configuration to our deployments.

If we want it to perform a reload based on secrets:

kind: Deployment
metadata:
  annotations:
    secret.reloader.stakater.com/reload: "secret"

And if we want to include additional secrets, we separate them with commas.

If, for example, we want to perform a rollout with a ConfigMap, we apply the same procedure as with secrets.

kind: Deployment
metadata:
  annotations:
    configmap.reloader.stakater.com/reload: "configmap-1,configmap-2"

Or if you want to add both, reloading for both secrets and configmaps:

apiVersion: apps/v1
  kind: Deployment
  metadata:
    annotations:
      secret.reloader.stakater.com/reload: "Secret-001,Secret-002"
      configmap.reloader.stakater.com/reload: "ConfigMap-001,ConfigMap002"

Autodiscovery with Reloader

Although you can manually add the secrets and configmaps in which to detect changes, one of its strong points is its self-discovery.

Typically, the name of the deployment and the configmap or secret are related. For instance, the deployment might be named ‘foo,’ and the configmap ‘foo-configmap.’ In this case, the change could be automatically discovered.

kind: Deployment
metadata:
  annotations:
    reloader.stakater.com/auto: "true"

Conclusion

In this article, using RELOADER for rollouts in Kubernetes, we have seen how useful this tool is for making changes to our configurations and ensuring they are applied. These tasks, which are often tedious, are greatly simplified thanks to tools like these.