Is your feature request related to a problem? Please describe.
In our kubernetes platform, we have many workloads where many Deployments, StatefulSets, and DaemonSets share common ConfigMaps and Secrets (e.g., trust bundles, TLS certificates). When a shared resource changes, Reloader triggers rolling restarts on all affected workloads simultaneously, which creates a sudden spike in the cluster due to the large number if new pods being scheduled at once.
The existing deployment.reloader.stakater.com/pause-period annotation partially addresses this, but it has two limitations:
Deployment-only — It does not support StatefulSets or DaemonSets, which are equally affected .
Annotation-based — Requires adding and maintaining an annotation on every workload individually. In environments managed by Helm/FluxCD, adding annotations to dozens of workloads across many charts creates significant configuration churn and operational burden. If the intent is to apply a pause globally, it should not require per-resource opt-in.
Describe the solution you'd like
- Global --pause-period flag
A new Reloader flag:
--pause-period=30s
When set, this would apply the pause-period behavior to all watched workloads (Deployments, StatefulSets, DaemonSets) without requiring any annotation. Individual workloads could still override via annotation (e.g., deployment.reloader.stakater.com/pause-period: "60s" would take precedence over the global default).
- Extend pause-period to StatefulSets and DaemonSets
The current pause-period mechanism (pause rollout → batch changes → resume) should work identically on StatefulSets and DaemonSets, not just Deployments. This would require corresponding annotations and the ability to overwrite these annotations.
statefulset.reloader.stakater.com/pause-period: "30s"
daemonset.reloader.stakater.com/pause-period: "30s"
Describe alternatives you've considered
Adding some random jitter to pause-period in deployments, but this method is not scalable and operationally challenging as we have multiple workloads.
Additional context
Add any other context or screenshots about the feature request here.
Is your feature request related to a problem? Please describe.
In our kubernetes platform, we have many workloads where many Deployments, StatefulSets, and DaemonSets share common ConfigMaps and Secrets (e.g., trust bundles, TLS certificates). When a shared resource changes, Reloader triggers rolling restarts on all affected workloads simultaneously, which creates a sudden spike in the cluster due to the large number if new pods being scheduled at once.
The existing deployment.reloader.stakater.com/pause-period annotation partially addresses this, but it has two limitations:
Deployment-only — It does not support StatefulSets or DaemonSets, which are equally affected .
Annotation-based — Requires adding and maintaining an annotation on every workload individually. In environments managed by Helm/FluxCD, adding annotations to dozens of workloads across many charts creates significant configuration churn and operational burden. If the intent is to apply a pause globally, it should not require per-resource opt-in.
Describe the solution you'd like
A new Reloader flag:
--pause-period=30s
When set, this would apply the pause-period behavior to all watched workloads (Deployments, StatefulSets, DaemonSets) without requiring any annotation. Individual workloads could still override via annotation (e.g., deployment.reloader.stakater.com/pause-period: "60s" would take precedence over the global default).
The current pause-period mechanism (pause rollout → batch changes → resume) should work identically on StatefulSets and DaemonSets, not just Deployments. This would require corresponding annotations and the ability to overwrite these annotations.
statefulset.reloader.stakater.com/pause-period: "30s"
daemonset.reloader.stakater.com/pause-period: "30s"
Describe alternatives you've considered
Adding some random jitter to pause-period in deployments, but this method is not scalable and operationally challenging as we have multiple workloads.
Additional context
Add any other context or screenshots about the feature request here.