// the find
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!
Reloader is a Kubernetes controller that watches ConfigMaps and Secrets and rolls the workloads that reference them (Deployments, StatefulSets, DaemonSets, Argo Rollouts, CronJobs), since Kubernetes doesn't do this natively. It's aimed at platform and DevOps engineers running anything where config or secret changes need to actually reach running pods without a manual kubectl rollout.
The annotation model is genuinely flexible: blanket auto-reload, named-resource reload, and a search/match opt-in pattern for multi-tenant clusters where you don't want every workload watching every secret. The annotations reload strategy specifically avoids pod-template mutation so GitOps tools like ArgoCD don't flag config drift, which is a real problem other reload solutions ignore. CSI Secrets Store Driver support (watching SecretProviderClassPodStatus) covers external secret stores like Vault or AWS Secrets Manager, which vanilla Kubernetes events don't expose at all. It also has a proper e2e test suite covering annotations, HA leader election, and multiple workload adapters, not just unit tests against mocks.
The --resources-to-ignore flag can only exclude ConfigMaps or Secrets, not both, and the documented workaround is scaling the whole controller to zero replicas, which is a clumsy escape hatch for something that should be a config option. The default env-vars strategy works by injecting a dummy environment variable into every matching container, which is effective but means your pod spec has an env var whose only job is to change on every reload. In annotations mode, a resource that's deleted and recreated with the same content won't be detected as changed since no prior state is tracked, so rebuild/restore flows can silently skip a reload. The README leads with an Enterprise upsell for CVE-free signed images with SBOM, implying the OSS images aren't signed or SBOM-tracked by default, worth checking before running in a compliance-sensitive cluster.