diff --git a/docs/Helm2-to-Helm3.md b/docs/Helm2-to-Helm3.md index 0b3fe6b..c55eae1 100644 --- a/docs/Helm2-to-Helm3.md +++ b/docs/Helm2-to-Helm3.md @@ -8,7 +8,7 @@ There are 3 steps involved in migrating the Reloader from Helm2 to Helm3. ### Step 1 -Install the helm-2to3 plugin +Install the `helm-2to3` plugin ```bash helm3 plugin install https://github.com/helm/helm-2to3 diff --git a/docs/How-it-works.md b/docs/How-it-works.md index 4240f50..4646d9f 100644 --- a/docs/How-it-works.md +++ b/docs/How-it-works.md @@ -1,12 +1,12 @@ -# How does Reloader work? +# 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`. -## How change detection works +## How Change Detection Works 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 +## Requirements for Rolling Upgrade To perform rolling upgrade a `deployment`, `daemonset` or `statefulset` must have @@ -37,13 +37,13 @@ metadata: Above mentioned annotation are also work for `Daemonsets` `Statefulsets` and `Rollouts` -## How Rolling upgrade works? +## 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 +### Environment Variable for ConfigMap If configmap name is foo then @@ -51,7 +51,7 @@ If configmap name is foo then STAKATER_FOO_CONFIGMAP ``` -### Environment variable for Secret +### Environment Variable for Secret If Secret name is foo then @@ -63,7 +63,7 @@ If the environment variable is found then it gets its value and compares it with Note: Rolling upgrade also works in the same way for secrets. -### Hash value Computation +### Hash Value Computation Reloader uses SHA1 to compute hash value. SHA1 is used because it is efficient and less prone to collision. @@ -77,6 +77,6 @@ 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 +## 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 configmap's or secret's 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`. diff --git a/docs/Reloader-vs-k8s-trigger-controller.md b/docs/Reloader-vs-k8s-trigger-controller.md index 7fea476..4a517fd 100644 --- a/docs/Reloader-vs-k8s-trigger-controller.md +++ b/docs/Reloader-vs-k8s-trigger-controller.md @@ -21,7 +21,7 @@ Reloader and k8s-trigger-controller are both built for same purpose. So there ar Reloader supports deployment `rollout` as well as `daemonsets` and `statefulsets` `rollout`. -### Hashing usage +### Hashing Usage #### `k8s-trigger-controller` diff --git a/docs/Verify-Reloader-Working.md b/docs/Verify-Reloader-Working.md index 8beb3a5..d9fff9b 100644 --- a/docs/Verify-Reloader-Working.md +++ b/docs/Verify-Reloader-Working.md @@ -2,7 +2,7 @@ Reloader's working can be verified by three ways. -## Verify from logs +## 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. @@ -14,11 +14,11 @@ Updated test-resource of type Deployment in namespace: test-reloader Below are the details that explain these logs: -### test-object +### `test-object` `test-object` is the name of a `secret` or a `deployment` in which change has been detected. -### SECRET +### `SECRET` `SECRET` is the type of `test-object`. It can either be `SECRET` or `CONFIGMAP` @@ -30,11 +30,11 @@ Below are the details that explain these logs: `test-resource` is the name of resource which is going to be updated -### Deployment +### `Deployment` `Deployment` is the type of `test-resource`. It can either be a `Deployment`, `Daemonset` or `Statefulset` -## Verify by checking the age of Pod +## 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. @@ -42,7 +42,7 @@ A pod's age can tell whether Reloader is working correctly or not. If you know t `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 +### Verify from Command Line After a change in `secret` or `configmap`. Run the below-mentioned command and verify that the pod is newly created. @@ -50,7 +50,7 @@ After a change in `secret` or `configmap`. Run the below-mentioned command and v kubectl get pods -n ``` -## Verify from metrics +## Verify From Metrics Some metrics are exported to Prometheus endpoint `/metrics` on port `9090`.