mirror of
https://github.com/stakater/Reloader.git
synced 2026-05-16 21:56:55 +00:00
Merge branch 'master' of github.com:stakater/Reloader into takeover-e2e-tests
This commit is contained in:
faizanahmad055
11
.github/workflows/pull_request.yaml
vendored
11
.github/workflows/pull_request.yaml
vendored
@@ -9,11 +9,6 @@ on:
|
||||
- '**'
|
||||
- '!.markdownlint.yaml'
|
||||
- '!.vale.ini'
|
||||
- '!Dockerfile-docs'
|
||||
- '!docs-nginx.conf'
|
||||
- '!docs/**'
|
||||
- '!theme_common'
|
||||
- '!theme_override'
|
||||
- '!deployments/kubernetes/chart/reloader/**'
|
||||
|
||||
env:
|
||||
@@ -50,14 +45,16 @@ jobs:
|
||||
|
||||
# Setting up helm binary
|
||||
- name: Set up Helm
|
||||
uses: azure/setup-helm@v4
|
||||
uses: azure/setup-helm@v5
|
||||
with:
|
||||
version: v3.11.3
|
||||
version: v3.20.2
|
||||
|
||||
- name: Helm chart unit tests
|
||||
uses: d3adb5/helm-unittest-action@v2
|
||||
with:
|
||||
charts: deployments/kubernetes/chart/reloader
|
||||
helm-version: v3.20.2
|
||||
github-token: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
- name: Set up Go
|
||||
uses: actions/setup-go@v6
|
||||
|
||||
34
.github/workflows/pull_request_docs.yaml
vendored
34
.github/workflows/pull_request_docs.yaml
vendored
@@ -1,34 +0,0 @@
|
||||
name: Pull Request for Documentation Changes
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
branches:
|
||||
- master
|
||||
paths:
|
||||
- '.markdownlint.yaml'
|
||||
- '.vale.ini'
|
||||
- 'Dockerfile-docs'
|
||||
- 'docs-nginx.conf'
|
||||
- 'docs/**'
|
||||
- '!docs/plans/**'
|
||||
- 'theme_common'
|
||||
- 'theme_override'
|
||||
- 'deployments/kubernetes/chart/reloader/README.md'
|
||||
|
||||
jobs:
|
||||
qa:
|
||||
uses: stakater/.github/.github/workflows/pull_request_doc_qa.yaml@v0.0.163
|
||||
with:
|
||||
MD_CONFIG: .github/md_config.json
|
||||
DOC_SRC: docs
|
||||
MD_LINT_CONFIG: .markdownlint.yaml
|
||||
build:
|
||||
uses: stakater/.github/.github/workflows/pull_request_container_build.yaml@v0.0.163
|
||||
with:
|
||||
DOCKER_FILE_PATH: Dockerfile-docs
|
||||
CONTAINER_REGISTRY_URL: ghcr.io/stakater
|
||||
PUSH_IMAGE: false
|
||||
secrets:
|
||||
CONTAINER_REGISTRY_USERNAME: ${{ github.actor }}
|
||||
CONTAINER_REGISTRY_PASSWORD: ${{ secrets.GHCR_TOKEN }}
|
||||
SLACK_WEBHOOK_URL: ${{ secrets.STAKATER_DELIVERY_SLACK_WEBHOOK }}
|
||||
5
.github/workflows/push-pr-image.yaml
vendored
5
.github/workflows/push-pr-image.yaml
vendored
@@ -8,11 +8,6 @@ on:
|
||||
paths:
|
||||
- '!.markdownlint.yaml'
|
||||
- '!.vale.ini'
|
||||
- '!Dockerfile-docs'
|
||||
- '!docs-nginx.conf'
|
||||
- '!docs/**'
|
||||
- '!theme_common'
|
||||
- '!theme_override'
|
||||
- '!deployments/kubernetes/chart/reloader/**'
|
||||
|
||||
env:
|
||||
|
||||
31
.github/workflows/push.yaml
vendored
31
.github/workflows/push.yaml
vendored
@@ -186,37 +186,6 @@ jobs:
|
||||
org.opencontainers.image.source=${{ github.event.repository.clone_url }}
|
||||
org.opencontainers.image.revision=${{ github.sha }}
|
||||
|
||||
- uses: dorny/paths-filter@v3
|
||||
id: filter
|
||||
with:
|
||||
filters: |
|
||||
docs:
|
||||
- '.markdownlint.yaml'
|
||||
- '.vale.ini'
|
||||
- 'Dockerfile-docs'
|
||||
- 'docs-nginx.conf'
|
||||
- 'docs/**'
|
||||
- 'README.md'
|
||||
- 'theme_common'
|
||||
- 'theme_override'
|
||||
|
||||
# run only if 'docs' files were changed
|
||||
- name: Build and Push Docker Image for Docs to ghcr registry
|
||||
if: steps.filter.outputs.docs == 'true'
|
||||
uses: docker/build-push-action@v6
|
||||
with:
|
||||
context: .
|
||||
file: Dockerfile-docs
|
||||
pull: true
|
||||
push: true
|
||||
build-args: BUILD_PARAMETERS=${{ env.BUILD_PARAMETERS }}
|
||||
cache-to: type=inline
|
||||
tags: |
|
||||
${{ env.GHCR_IMAGE_REPOSITORY }}/docs:merge-${{ github.event.number }}
|
||||
labels: |
|
||||
org.opencontainers.image.source=${{ github.event.repository.clone_url }}
|
||||
org.opencontainers.image.revision=${{ github.sha }}
|
||||
|
||||
- name: Push Latest Tag
|
||||
uses: anothrNick/github-tag-action@1.75.0
|
||||
env:
|
||||
|
||||
15
.github/workflows/release.yaml
vendored
15
.github/workflows/release.yaml
vendored
@@ -186,21 +186,6 @@ jobs:
|
||||
org.opencontainers.image.created=${{ steps.prep.outputs.created }}
|
||||
org.opencontainers.image.revision=${{ github.sha }}
|
||||
|
||||
- name: Build and Push Docker Image for Docs to ghcr registry
|
||||
uses: docker/build-push-action@v6
|
||||
with:
|
||||
context: .
|
||||
file: Dockerfile-docs
|
||||
pull: true
|
||||
push: true
|
||||
cache-to: type=inline
|
||||
tags: |
|
||||
${{ env.GHCR_IMAGE_REPOSITORY }}/docs:${{ steps.generate_tag.outputs.RELEASE_VERSION }}
|
||||
labels: |
|
||||
org.opencontainers.image.source=${{ github.event.repository.clone_url }}
|
||||
org.opencontainers.image.created=${{ steps.prep.outputs.created }}
|
||||
org.opencontainers.image.revision=${{ github.sha }}
|
||||
|
||||
##############################
|
||||
## Add steps to generate required artifacts for a release here(helm chart, operator manifest etc.)
|
||||
##############################
|
||||
|
||||
@@ -1,35 +0,0 @@
|
||||
FROM python:3.14-alpine as builder
|
||||
|
||||
# set workdir
|
||||
RUN mkdir -p $HOME/application
|
||||
WORKDIR $HOME/application
|
||||
|
||||
# copy the entire application
|
||||
COPY --chown=1001:root . .
|
||||
|
||||
RUN pip3 install -r theme_common/requirements.txt
|
||||
|
||||
# Combine Theme Resources
|
||||
RUN python theme_common/scripts/combine_theme_resources.py -s theme_common/resources -ov theme_override/resources -o dist/_theme
|
||||
# Produce mkdocs file
|
||||
RUN python theme_common/scripts/combine_mkdocs_config_yaml.py theme_common/mkdocs.yml theme_override/mkdocs.yml mkdocs.yml
|
||||
|
||||
# build the docs
|
||||
RUN mkdocs build
|
||||
|
||||
FROM nginxinc/nginx-unprivileged:1.29-alpine as deploy
|
||||
COPY --from=builder $HOME/application/site/ /usr/share/nginx/html/reloader/
|
||||
COPY docs-nginx.conf /etc/nginx/conf.d/default.conf
|
||||
|
||||
# set non-root user
|
||||
USER 1001
|
||||
|
||||
LABEL name="Stakater Reloader Documentation" \
|
||||
maintainer="Stakater <hello@stakater.com>" \
|
||||
vendor="Stakater" \
|
||||
release="1" \
|
||||
summary="Documentation for Stakater Reloader"
|
||||
|
||||
EXPOSE 8080:8080/tcp
|
||||
|
||||
CMD ["nginx", "-g", "daemon off;"]
|
||||
@@ -19,6 +19,8 @@ In a traditional Kubernetes setup, updating a `Secret` or `ConfigMap` does not a
|
||||
|
||||
Reloader bridges that gap by ensuring your workloads stay in sync with configuration changes — automatically and safely.
|
||||
|
||||
📚 Full documentation is available at [Stakater documentation site](https://docs.stakater.com/reloader/)
|
||||
|
||||
## 🚀 Why Reloader?
|
||||
|
||||
- ✅ **Zero manual restarts**: No need to manually rollout workloads after config/secret changes.
|
||||
@@ -465,10 +467,6 @@ If you're running Reloader in production, we'd love to hear from you:
|
||||
|
||||
## Help
|
||||
|
||||
### 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.
|
||||
|
||||
### Have a question?
|
||||
|
||||
File a GitHub [issue](https://github.com/stakater/Reloader/issues).
|
||||
|
||||
@@ -1,11 +0,0 @@
|
||||
server {
|
||||
listen 8080;
|
||||
root /usr/share/nginx/html/;
|
||||
index index.html;
|
||||
error_page 403 404 /404.html;
|
||||
location = /404.html {
|
||||
internal;
|
||||
}
|
||||
# redirects issued by nginx will be relative
|
||||
absolute_redirect off;
|
||||
}
|
||||
@@ -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)
|
||||
@@ -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)
|
||||
@@ -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
|
||||
```
|
||||
@@ -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`.
|
||||
@@ -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 |
|
||||
@@ -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>`
|
||||
@@ -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
|
||||
@@ -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`.
|
||||
@@ -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">
|
||||
|
||||
[](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>
|
||||
|
||||
---
|
||||
Submodule theme_common deleted from 11286e112e
@@ -1,22 +0,0 @@
|
||||
site_name: Stakater Reloader
|
||||
docs_dir: docs
|
||||
site_url: https://docs.stakater.com/reloader/
|
||||
repo_url: https://github.com/stakater/reloader
|
||||
edit_uri: blob/master/docs/
|
||||
|
||||
theme:
|
||||
favicon: assets/images/favicon.svg
|
||||
|
||||
nav:
|
||||
- index.md
|
||||
- How-to Guides:
|
||||
- Verify-Reloader-Working.md
|
||||
- Alerting.md
|
||||
- Reloader-with-Sealed-Secrets.md
|
||||
- Helm2-to-Helm3.md
|
||||
- References:
|
||||
- How-it-works.md
|
||||
- Container Build.md
|
||||
- Comparisons with similar tools:
|
||||
- Reloader-vs-ConfigmapController.md
|
||||
- Reloader-vs-k8s-trigger-controller.md
|
||||
0
theme_override/resources/.gitignore
vendored
0
theme_override/resources/.gitignore
vendored
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 10 KiB |
Reference in New Issue
Block a user