You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+64-5Lines changed: 64 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@
13
13
14
14
## 🔁 What is Reloader?
15
15
16
-
Reloader is a Kubernetes controller that automatically triggers rollouts of workloads (like Deployments, StatefulSets, and more) whenever referenced `Secrets` or `ConfigMaps` are updated.
16
+
Reloader is a Kubernetes controller that automatically triggers rollouts of workloads (like Deployments, StatefulSets, and more) whenever referenced `Secrets`, `ConfigMaps` or **optionally CSI-mounted secrets** are updated.
17
17
18
18
In a traditional Kubernetes setup, updating a `Secret` or `ConfigMap` does not automatically restart or redeploy your workloads. This can lead to stale configurations running in production, especially when dealing with dynamic values like credentials, feature flags, or environment configs.
19
19
@@ -169,9 +169,11 @@ metadata:
169
169
170
170
This instructs Reloader to skip all reload logic for that resource across all workloads.
By default, Reloader uses the **rollout** strategy — it updates the pod template to trigger a new rollout. This works well in most cases, but it can cause problems if you're using GitOps tools like ArgoCD, which detect this as configuration drift.
174
+
Note: This is only applicable when using [Argo Rollouts](https://argoproj.github.io/argo-rollouts/). It is ignored for standard Kubernetes `Deployments`, `StatefulSets`, or `DaemonSets`. To use this feature, Argo Rollouts support must be enabled in Reloader (for example via --is-argo-rollouts=true).
175
+
176
+
By default, Reloader triggers the Argo Rollout controller to perform a standard rollout by updating the pod template. This works well in most cases, however, because this modifies the workload spec, GitOps tools like ArgoCD will detect this as "Configuration Drift" and mark your application as OutOfSync.
175
177
176
178
To avoid that, you can switch to the **restart** strategy, which simply restarts the pod without changing the pod template.
177
179
@@ -192,6 +194,8 @@ metadata:
192
194
1. You want a quick restart without changing the workload spec
193
195
1. Your platform restricts metadata changes
194
196
197
+
This setting affects Argo Rollouts behavior, not Argo CD sync settings.
- `reloader.stakater.com/auto`and `reloader.stakater.com/search` **cannot be used together** — the `auto` annotation takes precedence.
@@ -239,6 +243,61 @@ This feature allows you to pause rollouts for a deployment for a specified durat
239
243
1. ✅ Your deployment references multiple ConfigMaps or Secrets that may be updated at the same time.
240
244
1. ✅ You want to minimize unnecessary rollouts and reduce downtime caused by back-to-back configuration changes.
241
245
246
+
### 8. 🔐 CSI Secret Provider Support
247
+
248
+
Reloader supports the [Secrets Store CSI Driver](https://secrets-store-csi-driver.sigs.k8s.io/), which allows mounting secrets from external secret stores (like AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) directly into pods.
249
+
Unlike Kubernetes Secret objects, CSI-mounted secrets do not always trigger native Kubernetes update events. Reloader solves this by watching CSI status resources and restarting affected workloads when mounted secret versions change.
250
+
251
+
#### How it works
252
+
253
+
When secret rotation is enabled, the Secrets Store CSI Driver updates a Kubernetes resource called: `SecretProviderClassPodStatus`
254
+
255
+
This resource reflects the currently mounted secret versions for a pod.
256
+
Reloader watches these updates and triggers a rollout when a change is detected.
257
+
258
+
#### Prerequisites
259
+
260
+
- Secrets Store CSI Driver must be installed in your cluster
261
+
- Secret rotation enabled in the CSI driver.
262
+
- Enable CSI integration in Reloader: `--enable-csi-integration=true`
| `reloader.stakater.com/auto: "true"` | Global Discovery: Automatically discovers and reloads the workload when any mounted ConfigMap or Secret is updated. |
269
+
| `secretproviderclass.reloader.stakater.com/auto: 'true'` | CSI Discovery: Specifically watches for updates to all SecretProviderClasses used by the workload (CSI driver integration). |
270
+
| `secretproviderclass.reloader.stakater.com/reload: "my-secretproviderclass"` | Targeted Reload: Only reloads the workload when the specifically named SecretProviderClass(es) are updated. |
271
+
272
+
Reloader monitors changes at the **per-secret level** by watching the `SecretProviderClassPodStatus`. Make sure each secret you want to monitor is properly defined with a `secretKey` in your `SecretProviderClass`:
273
+
274
+
```yaml
275
+
apiVersion: secrets-store.csi.x-k8s.io/v1
276
+
kind: SecretProviderClass
277
+
metadata:
278
+
name: vault-reloader-demo
279
+
namespace: test
280
+
spec:
281
+
provider: vault
282
+
parameters:
283
+
vaultAddress: "http://vault.vault.svc:8200"
284
+
vaultSkipTLSVerify: "true"
285
+
roleName: "demo-role"
286
+
objects: |
287
+
- objectName: "password"
288
+
secretPath: "secret/data/reloader-demo"
289
+
secretKey: "password"
290
+
```
291
+
292
+
***Important***: Reloader tracks changes to individual secrets (identified by `secretKey`). If your SecretProviderClass doesn't specify `secretKey` for each object, Reloader may not detect updates correctly.
293
+
294
+
#### Notes & Limitations
295
+
296
+
Reloader reacts to CSI status changes, not direct updates to external secret stores
297
+
Secret rotation must be enabled in the CSI driver for updates to be detected
298
+
CSI limitations (such as `subPath` mounts) still apply and may require pod restarts
299
+
If secrets are synced to Kubernetes Secret objects, standard Reloader behavior applies and CSI support may not be required
300
+
242
301
## 🚀 Installation
243
302
244
303
### 1. 📦 Helm
@@ -430,7 +489,7 @@ PRs are welcome. In general, we follow the "fork-and-pull" Git workflow:
430
489
431
490
## Release Processes
432
491
433
-
_Repository GitHub releases_: As requested by the community in [issue 685](https://github.com/stakater/Reloader/issues/685), Reloader is now based on a manual release process. Releases are no longer done on every merged PR to the main branch, but manually on request.
492
+
*Repository GitHub releases*: As requested by the community in [issue 685](https://github.com/stakater/Reloader/issues/685), Reloader is now based on a manual release process. Releases are no longer done on every merged PR to the main branch, but manually on request.
434
493
435
494
To make a GitHub release:
436
495
@@ -443,7 +502,7 @@ To make a GitHub release:
443
502
1. Code owners create another branch from `master` and bump the helm chart version as well as Reloader image version.
444
503
- Code owners create a PR with `release/helm-chart` label, example: [PR-846](https://github.com/stakater/Reloader/pull/846)
445
504
446
-
_Repository git tagging_: Push to the main branch will create a merge-image and merge-tag named `merge-${{ github.event.number }}`, for example `merge-800` when pull request number 800 is merged.
505
+
*Repository git tagging*: Push to the main branch will create a merge-image and merge-tag named `merge-${{ github.event.number }}`, for example `merge-800` when pull request number 800 is merged.
Copy file name to clipboardExpand all lines: docs/Reloader-vs-ConfigmapController.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,10 +2,10 @@
2
2
3
3
Reloader is inspired from [`configmapcontroller`](https://github.com/fabric8io/configmapcontroller) but there are many ways in which it differs from `configmapcontroller`. Below is the small comparison between these two controllers.
| Reloader can watch both `Secrets` and `ConfigMaps`. |`configmapcontroller` can only watch changes in `ConfigMaps`. It cannot detect changes in other resources like `Secrets`. |
8
-
| Reloader can perform rolling upgrades on `deployments` as well as on `statefulsets` and `daemonsets`|`configmapcontroller` can only perform rolling upgrades on `deployments`. It currently does not support rolling upgrades on `statefulsets` and `daemonsets`|
9
-
| Reloader provides both unit test cases and end to end integration test cases for future updates. So one can make sure that new changes do not break any old functionality. | Currently there are not any unit test cases or end to end integration test cases in `configmap-controller`. It add difficulties for any additional updates in `configmap-controller` and one can not know for sure whether new changes breaks any old functionality or not. |
10
-
| Reloader uses SHA1 to encode the change in `ConfigMap` or `Secret`. It then saves the SHA1 value in `STAKATER_FOO_CONFIGMAP` or `STAKATER_FOO_SECRET` environment variable depending upon where the change has happened. The use of SHA1 provides a concise 40 characters encoded value that is very less prone to collision. |`configmap-controller` uses `FABRICB_FOO_REVISION` environment variable to store any change in `ConfigMap` controller. It does not encode it or convert it in suitable hash value to avoid data pollution in deployment. |
11
-
| Reloader allows you to customize your own annotation (for both `Secrets` and `ConfigMaps`) using command line flags |`configmap-controller` restricts you to only their provided annotation |
| Reloader can watch both `Secrets` and `ConfigMaps`. |`configmapcontroller` can only watch changes in `ConfigMaps`. It cannot detect changes in other resources like `Secrets`.|
8
+
| Reloader can perform rolling upgrades on `deployments` as well as on `statefulsets` and `daemonsets`|`configmapcontroller` can only perform rolling upgrades on `deployments`. It currently does not support rolling upgrades on `statefulsets` and `daemonsets`|
9
+
| Reloader provides both unit test cases and end to end integration test cases for future updates. So one can make sure that new changes do not break any old functionality. | Currently there are not any unit test cases or end to end integration test cases in `configmap-controller`. It adds difficulties for any additional updates in `configmap-controller` and one can not know for sure whether new changes breaks any old functionality or not. |
10
+
| Reloader uses SHA1 to encode the change in `ConfigMap` or `Secret`. It then saves the SHA1 value in `STAKATER_FOO_CONFIGMAP` or `STAKATER_FOO_SECRET` environment variable depending upon where the change has happened. The use of SHA1 provides a concise 40 characters encoded value that is very less prone to collision. |`configmap-controller` uses `FABRICB_FOO_REVISION` environment variable to store any change in `ConfigMap` controller. It does not encode it or convert it in suitable hash value to avoid data pollution in deployment.|
11
+
| Reloader allows you to customize your own annotation (for both `Secrets` and `ConfigMaps`) using command line flags |`configmap-controller` restricts you to only their provided annotation|
0 commit comments