reloader

Changing a Kubernetes ConfigMap or Secret does not guarantee that a running application will reload its contents. Stakater Reloader watches selected configuration objects and triggers workload rollouts when they change, allowing replacement pods to start with the updated settings. It is useful for applications that read configuration only at startup. Choose its scope carefully: automatic restarts affect availability, and an application that already reloads safely may not need a rollout for every configuration change.

Current guidance

The historical chart packages Stakater Reloader, which watches configuration changes and triggers workload rollouts. Current upstream announces a v2 implementation based on Operator SDK; the v1 master branch is feature-frozen with security and critical fixes only. This is a version-selection decision, not evidence that every existing Reloader deployment is retired.

Decide which workloads should restart and which already reload configuration safely. Broad automatic reload annotations can turn frequent Secret rotation into widespread restarts, while a StatefulSet may have ordering and availability requirements unlike a web Deployment. Review namespace scope, controller RBAC and interactions with GitOps reconciliation before enabling discovery across the cluster.

When replacing the archived chart or moving major versions, inventory annotations, watched objects, rollout strategy and excluded namespaces. Change a harmless test ConfigMap and confirm the actual application observes the new value, not just that a rollout was requested. Also test an irrelevant change that should do nothing. Preserve a way to pause automated restarts during incident response; no version migration or outage-free rollout is certified by this advisory.