github/Reloader
1
0
Fork 0
mirror of https://github.com/stakater/Reloader.git synced 2026-05-16 21:56:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

remove docs

Browse Source
This commit is contained in:
Rasheed Amir
2026-05-11 07:45:49 +02:00
parent 9294193f86
commit 37f3795233
10 changed files with 1 additions and 405 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@@ -467,7 +467,7 @@ If you're running Reloader in production, we'd love to hear from you:
### Documentation
The Reloader documentation can be viewed from [the doc site](https://docs.stakater.com/reloader/). The doc source is in the [docs](./docs/) folder.
The Reloader documentation can be viewed from [the doc site](https://docs.stakater.com/reloader/).
### Have a question?

18
docs/Alerting.md
View File

@@ -1,18 +0,0 @@
# Alerting on Reload
Reloader can alert when it triggers a rolling upgrade on Deployments or StatefulSets. Webhook notification alert would be sent to the configured webhook server with all the required information.
## Enabling
In-order to enable this feature, you need to update the `reloader.env.secret` section of `values.yaml` providing the information needed for alert:
```yaml
ALERT_ON_RELOAD: [ true/false ] Default: false
ALERT_SINK: [ slack/teams/gchat/webhook ] Default: webhook
ALERT_WEBHOOK_URL: Required if ALERT_ON_RELOAD is true
ALERT_ADDITIONAL_INFO: Any additional information to be added to alert
```
## Slack Incoming-Webhook Creation Docs
[Sending messages using Incoming Webhooks](https://api.slack.com/messaging/webhooks)

53
docs/Container Build.md
View File

@@ -1,53 +0,0 @@
# Container Build
> **WARNING:** As a user of Reloader there is no need to build containers, the open source version is available on [Docker Hub](https://hub.docker.com/r/stakater/reloader/).
Multi-architecture approach is based on original work by [@mdh02038](https://github.com/mdh02038/Reloader).
Images are tested on linux/arm, linux/arm64 and linux/amd64.
## Install Pre-Reqs
The build environment requires the following packages (tested on `Ubuntu 20.04`):
* Golang
* `make`
* `qemu` (for arm, arm64 etc. emulation)
* binfmt-support
* Docker engine
## Docker
Follow instructions on [Install using the apt repository](https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository).
Once installed, enable the experimental CLI:
```bash
export DOCKER_CLI_EXPERIMENTAL=enabled
```
Login to enable publishing of packages:
```bash
sudo docker login
```
## Remaining Pre-Reqs
Remaining Pre-Reqs can be installed via:
```bash
sudo apt install golang make qemu-user-static binfmt-support -y
```
## Publish Multi-Architecture Image
To build/ publish multi-arch Docker images clone repository and execute from repository root:
```bash
sudo make release-all
```
## Additional Links/Info
[Building Multi-Architecture Docker Images With `Buildx`](https://medium.com/@artur.klauser/building-multi-architecture-docker-images-with-buildx-27d80f7e2408)

68
docs/Helm2-to-Helm3.md
View File

@@ -1,68 +0,0 @@
# Helm2 to Helm3 Migration
Follow below-mentioned instructions to migrate Reloader from Helm2 to Helm3
## Instructions
There are 3 steps involved in migrating the Reloader from Helm2 to Helm3.
### Step 1
Install the `helm-2to3` plugin
```bash
helm3 plugin install https://github.com/helm/helm-2to3
helm3 2to3 convert <release-name>
helm3 2to3 cleanup --release-cleanup --skip-confirmation
```
### Step 2
Add the following Helm3 labels and annotations on Reloader resources.
Label:
```yaml
app.kubernetes.io/managed-by=Helm
```
Annotations:
```yaml
meta.helm.sh/release-name=<release-name>
meta.helm.sh/release-namespace=<namespace>
```
For example, to label and annotate the ClusterRoleBinding and ClusterRole:
```bash
KIND=ClusterRoleBinding
NAME=reloader-reloader-role-binding
RELEASE=reloader
NAMESPACE=kube-system
kubectl annotate $KIND $NAME meta.helm.sh/release-name=$RELEASE
kubectl annotate $KIND $NAME meta.helm.sh/release-namespace=$NAMESPACE
kubectl label $KIND $NAME app.kubernetes.io/managed-by=Helm
KIND=ClusterRole
NAME=reloader-reloader-role
RELEASE=reloader
NAMESPACE=kube-system
kubectl annotate $KIND $NAME meta.helm.sh/release-name=$RELEASE
kubectl annotate $KIND $NAME meta.helm.sh/release-namespace=$NAMESPACE
kubectl label $KIND $NAME app.kubernetes.io/managed-by=Helm
```
### Step 3
Upgrade to desired version
```bash
helm3 repo add stakater https://stakater.github.io/stakater-charts
helm3 repo update
helm3 upgrade <release-name> stakater/reloader --version=v0.0.72
```

93
docs/How-it-works.md
View File

@@ -1,93 +0,0 @@
# How Does Reloader Work?
Reloader watches for `ConfigMap` and `Secret` and detects if there are changes in data of these objects. After change detection Reloader performs rolling upgrade on relevant Pods via associated `Deployment`, `Daemonset` and `Statefulset`:
```mermaid
flowchart LR
subgraph Reloader
controller("Controller watches in a loop") -- "Detects a change" --> upgrade_handler("Upgrade handler checks if the change is a valid data change by comparing the change hash")
upgrade_handler -- "Update resource" --> update_resource("Updates the resource with computed hash of change")
end
Reloader -- "Watches" --> secret_configmaps("Secrets/ConfigMaps")
Reloader -- "Updates resources with Reloader environment variable" --> resources("Deployments/DaemonSets/StatefulSets resources with Reloader annotation")
resources -- "Restart pods based on StrategyType" --> Pods
```
## How Does Change Detection Work?
Reloader watches changes in `ConfigMaps` and `Secrets` data. As soon as it detects a change in these. It forwards these objects to an update handler which decides if and how to perform the rolling upgrade.
## Requirements for Rolling Upgrade
To perform rolling upgrade a `deployment`, `daemonset` or `statefulset` must have
- support for rolling upgrade strategy
- specific annotation for `ConfigMaps` or `Secrets`
The annotation value is comma separated list of `ConfigMaps` or `Secrets`. If a change is detected in data of these `ConfigMaps` or `Secrets`, Reloader will perform rolling upgrades on their associated `deployments`, `daemonsets` or `statefulsets`.
### Annotation for ConfigMap
For a `Deployment` called `foo` have a `ConfigMap` called `foo`. Then add this annotation* to your `Deployment`, where the default annotation can be changed with the `--configmap-annotation` flag:
```yaml
metadata:
annotations:
configmap.reloader.stakater.com/reload: "foo"
```
### Annotation for Secret
For a `Deployment` called `foo` have a `Secret` called `foo`. Then add this annotation to your `Deployment`, where the default annotation can be changed with the `--secret-annotation` flag:
```yaml
metadata:
annotations:
secret.reloader.stakater.com/reload: "foo"
```
Above mentioned annotation are also work for `Daemonsets` `Statefulsets` and `Rollouts`
## How Does Rolling Upgrade Work?
When Reloader detects changes in `ConfigMap`. It gets two objects of `ConfigMap`. First object is an old `ConfigMap` object which has a state before the latest change. Second object is new `ConfigMap` object which contains latest changes. Reloader compares both objects and see whether any change in data occurred or not. If Reloader finds any change in new `ConfigMap` object, only then, it moves forward with rolling upgrade.
After that, Reloader gets the list of all `deployments`, `daemonsets` and `statefulset` and looks for above mentioned annotation for `ConfigMap`. If the annotation value contains the `ConfigMap` name, it then looks for an environment variable which can contain the `ConfigMap` or secret data change hash.
### Environment Variable for ConfigMap
If `ConfigMap` name is foo then
```yaml
STAKATER_FOO_CONFIGMAP
```
### Environment Variable for Secret
If Secret name is foo then
```yaml
STAKATER_FOO_SECRET
```
If the environment variable is found then it gets its value and compares it with new `ConfigMap` hash value. If old value in environment variable is different from new hash value then Reloader updates the environment variable. If the environment variable does not exist then it creates a new environment variable with latest hash value from `ConfigMap` and updates the relevant `deployment`, `daemonset` or `statefulset`
Note: Rolling upgrade also works in the same way for secrets.
### Hash Value Computation
Reloader uses SHA1 to compute hash value. SHA1 is used because it is efficient and less prone to collision.
## Monitor All Namespaces
By default Reloader deploys in default namespace and monitors changes in all namespaces. To monitor changes in a specific namespace deploy the Reloader in that namespace and set the `watchGlobally` flag to `false` in values file located under `deployments/kubernetes/chart/reloader` and render manifest file using helm command:
```bash
helm --namespace {replace this with namespace name} template . > reloader.yaml
```
The output file can then be used to deploy Reloader in specific namespace.
## Compatibility With Helm Install and Upgrade
Reloader has no impact on helm deployment cycle. Reloader only injects an environment variable in `deployment`, `daemonset` or `statefulset`. The environment variable contains the SHA1 value of `ConfigMaps` or `Secrets` data. So if a deployment is created using Helm and Reloader updates the deployment, then next time you upgrade the helm release, Reloader will do nothing except changing that environment variable value in `deployment` , `daemonset` or `statefulset`.

11
docs/Reloader-vs-ConfigmapController.md
View File

@@ -1,11 +0,0 @@
# Reloader vs ConfigmapController
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 | ConfigMap |
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Reloader can watch both `Secrets` and `ConfigMaps`. | `configmapcontroller` can only watch changes in `ConfigMaps`. It cannot detect changes in other resources like `Secrets`. |
| 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` |
| 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. |
| 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. |
| 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 |

46
docs/Reloader-vs-k8s-trigger-controller.md
View File

@@ -1,46 +0,0 @@
# Reloader vs k8s-trigger-controller
Reloader and k8s-trigger-controller are both built for same purpose. So there are quite a few similarities and differences between these.
## Similarities
- Both controllers support change detection in `ConfigMaps` and `Secrets`
- Both controllers support deployment `rollout`
- Reloader controller use SHA1 for hashing
- Both controllers have end to end as well as unit test cases.
## Differences
### Support for `Daemonsets` and `Statefulsets`
#### `k8s-trigger-controller`
`k8s-trigger-controller` only support for deployment `rollout`. It does not support `daemonsets` and `statefulsets` `rollout`.
#### Reloader
Reloader supports deployment `rollout` as well as `daemonsets` and `statefulsets` `rollout`.
### Hashing Usage
#### `k8s-trigger-controller`
`k8s-trigger-controller` stores the hash value in an annotation `trigger.k8s.io/[secret|configMap]-NAME-last-hash`
#### Reloader
Reloader stores the hash value in an environment variable `STAKATER_NAME_[SECRET|CONFIGMAP]`
### Customization
#### `k8s-trigger-controller`
`k8s-trigger-controller` restricts you to using the `trigger.k8s.io/[secret-configMap]-NAME-last-hash` annotation
#### Reloader
Reloader allows you to customize the annotation to fit your needs with command line flags:
- `--auto-annotation <annotation>`
- `--configmap-annotation <annotation>`
- `--secret-annotation <annotation>`

14
docs/Reloader-with-Sealed-Secrets.md
View File

@@ -1,14 +0,0 @@
# Using Reloader with Sealed Secrets
Below are the steps to use Reloader with Sealed Secrets:
1. Download and install the kubeseal client from [here](https://github.com/bitnami-labs/sealed-secrets)
1. Install the controller for Sealed Secrets
1. Fetch the encryption certificate
1. Encrypt the secret
1. Apply the secret
1. Install the tool which uses that Sealed Secret
1. Install Reloader
1. Once everything is setup, update the original secret at client and encrypt it with kubeseal to see Reloader working
1. Apply the updated Sealed Secret
1. Reloader will restart the pod to use that updated secret

75
docs/Verify-Reloader-Working.md
View File

@@ -1,75 +0,0 @@
# Verify Reloader's Working
Reloader's working can be verified by three ways.
## Verify From Logs
Check the logs of Reloader and verify that you can see logs looks like below, if you are able to find these logs then it means Reloader is working.
```text
Changes Detected in test-object of type 'SECRET' in namespace: test-reloader
Updated test-resource of type Deployment in namespace: test-reloader
```
Below are the details that explain these logs:
### `test-object`
`test-object` is the name of a `secret` or a `configmap` in which change has been detected.
### `SECRET`
`SECRET` is the type of `test-object`. It can either be `SECRET` or `CONFIGMAP`
### `test-reloader`
`test-reloader` is the name of namespace in which Reloader has detected the change.
### `test-resource`
`test-resource` is the name of resource which is going to be updated
### `Deployment`
`Deployment` is the type of `test-resource`. It can either be a `Deployment`, `Daemonset` or `Statefulset`
## Verify by Checking the Age of Pod
A pod's age can tell whether Reloader is working correctly or not. If you know that a change in a `secret` or `configmap` has occurred, then check the relevant Pod's age immediately. It should be newly created few moments ago.
### Verify from Kubernetes Dashboard
`kubernetes dashboard` can be used to verify the working of Reloader. After a change in `secret` or `configmap`, check the relevant Pod's age from dashboard. It should be newly created few moments ago.
### Verify from Command Line
After a change in `secret` or `configmap`. Run the below-mentioned command and verify that the pod is newly created.
```bash
kubectl get pods <pod name> -n <namespace name>
```
## Verify From Metrics
Some metrics are exported to Prometheus endpoint `/metrics` on port `9090`.
When Reloader is unable to reload, `reloader_reload_executed_total{success="false"}` metric gets incremented and when it reloads successfully, `reloader_reload_executed_total{success="true"}` gets incremented. You will be able to see the following metrics, with some other metrics, at `/metrics` endpoint.
```text
reloader_reload_executed_total{success="false"} 15
reloader_reload_executed_total{success="true"} 12
```
### Reloads by Namespace
Reloader can also export a metric to show the number of reloads by namespace. This feature is disabled by default, as it can lead to high cardinality in clusters with many namespaces.
The metric will have both `success` and `namespace` as attributes:
```text
reloader_reload_executed_total{success="false", namespace="some-namespace"} 2
reloader_reload_executed_total{success="true", namespace="some-namespace"} 1
```
To opt in, set the environment variable `METRICS_COUNT_BY_NAMESPACE` to `enabled` or set the Helm value `reloader.enableMetricsByNamespace` to `true`.

26
docs/index.md
View File

@@ -1,26 +0,0 @@
# Introduction
Reloader can watch changes in `ConfigMap` and `Secret` and do rolling upgrades on Pods with their associated `DeploymentConfigs`, `Deployments`, `Daemonsets` `Statefulsets` and `Rollouts`.
These are the key features of Reloader:
1. Restart pod in a `deployment` on change in linked/related `ConfigMaps` or `Secrets`
1. Restart pod in a `daemonset` on change in linked/related `ConfigMaps` or `Secrets`
1. Restart pod in a `statefulset` on change in linked/related `ConfigMaps` or `Secrets`
1. Restart pod in a `rollout` on change in linked/related `ConfigMaps` or `Secrets`
This site contains more details on how Reloader works. For an overview, please see the repository's [README file](https://github.com/stakater/Reloader/blob/master/README.md).
---
<div align="center">
[![💖 Sponsor our work](https://img.shields.io/badge/Sponsor%20Our%20Work-FF8C00?style=for-the-badge&logo=github-sponsors&logoColor=white)](https://github.com/sponsors/stakater?utm_source=docs&utm_medium=footer&utm_campaign=reloader)
<p>
Your support funds maintenance, security updates, and new features for Reloader, plus continued investment in other open source tools.
</p>
</div>
---