Reloader

Reloader copied to clipboard

I have made below changes in my configMap and deployment.yaml file respectively to restart pod whenever configmap gets updated. But my pod is not getting restarted when i update my configmap.

kind: ConfigMap metadata: name: frontend-conf annotations: reloader.stakater.com/match: "true" namespace: test-ns

kind: Deployment metadata: name: {{ .Values.name }} namespace: {{ .Values.namespace }} annotations: reloader.stakater.com/search: "true"

Am i missing anything here?

I would like to second this, i can share any relevant information if that would help.

@sn-asownie @rishindra-singh can you please share the version of kubernetes and reloader?

We just experienced this on a GKE cluster under normal operational circumstances

CP version: 1.21.12-gke.1500 Node pool: 1.20.12-gke.1500 Reloader: stakater/reloader:v0.0.110

Hi, @CMorton737, @rishindra-singh, @sn-asownie I just tested this again, it is working. Please share a sample deployment and configmap with the correct indentation that is not working for you and I can test it. So far, I am not able to reproduce this bug. It is working as intended and the pod is being restarted.

Following up on this -- this always works for me when making edits directly to the ConfigMap via kubectl, but never works when the update to the ConfigMap via Helm.

Hello again, I finally had time to do a deeper level of troubleshooting here. Our organization uses a single genericized Helm chart for our microservice suite. The behavior described in my comment above, where ConfigMap changes made by Helm were failing to trigger Reloader, was due to the specific behavior of our Helm chart. Rather than making updates to the existing ConfigMap, it was doing a full recreation each time a value changed. Reloader is not configured to trigger rollout restarts on ConfigMap/Secret creation by default.

Changing .Values.reloader.reloadOnCreate to true on Reloader fixed the issue for me. Hopefully this information is helpful to others in this thread.

Hello again, I finally had time to do a deeper level of troubleshooting here. Our organization uses a single genericized Helm chart for our microservice suite. The behavior described in my comment above, where ConfigMap changes made by Helm were failing to trigger Reloader, was due to the specific behavior of our Helm chart. Rather than making updates to the existing ConfigMap, it was doing a full recreation each time a value changed. Reloader is not configured to trigger rollout restarts on ConfigMap/Secret creation by default.

Changing .Values.reloader.reloadOnCreate to true on Reloader fixed the issue for me. Hopefully this information is helpful to others in this thread.

This worked for me.

Closing this issue as solved now.