After talking about change propagation in configmaps here, I would like to go deeper into the Reloader controller.
What is ConfigMap Reloader?
ConfigMap Reloader is an open-source Kubernetes controller that automatically triggers rolling upgrades when ConfigMaps or Secrets are updated. It is useful in scenarios where your application relies on external configuration files.
Without a tool like ConfigMap Reloader, you might need to manually delete or restart your pods to have your app using the new configuration, which can be cumbersome and prone to error, especially in larger deployments.
How Does ConfigMap Reloader Work?
ConfigMap Reloader works by monitoring changes in the ConfigMaps and Secrets used within your pods managed by a Deployment for instance. When it detects a change, it triggers a rolling update of the pods, ensuring that the new configuration is reflected.
Here’s a step-by-step overview of how ConfigMap Reloader works:
- Monitor ConfigMaps/Secrets: ConfigMap Reloader continuously watches for changes in the specified ConfigMaps and Secrets in the Kubernetes cluster.
- Detect Changes: When a change is detected — whether it’s a modification, deletion, or addition — the reloader takes note.
- Triggers Rolling Update: ConfigMap Reloader then triggers a rolling restart of the affected pods. This ensures that the new configuration is applied without any downtime.
- Changes are picked up: The restarted pods pick up the updated ConfigMaps or Secrets upon startup, ensuring that the latest configurations are in effect.
How to use ConfigMap Reloader in Your Kubernetes Cluster
Using ConfigMap Reloader into your Kubernetes environment is a simple process. Here’s a basic guide to get you started:
Deploy the Reloader
First, you need to deploy the Reloader into your Kubernetes cluster.
Since sometimes there are issues with tagging in the container registry, I recommend downloading a specific version. At the time of writing I cloned the repo at this link. It uses version 1.0.121.
After that, you can go to the folder ./deployments/kubernetes and build your installation manifest with Kustomize:
kustomize build . > reloader-install.yaml
kubectl apply -f reloader-install.yaml
kubectl get pod
NAME READY STATUS RESTARTS AGE
reloader-reloader-8c4c8b6f9-b2b6g 1/1 Running 0 43s
Add resources properly annotated
To make sure that the Reloader refreshes objects like Deployments on ConfigMap and Secrets updates, you need to annotate it properly:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
annotations:
reloader.stakater.com/auto: "true"
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
volumeMounts:
- name: config-volume
mountPath: /usr/share/nginx/html/
volumes:
- name: config-volume
configMap:
name: my-configmap
---
apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
data:
index.html: |
<html>
…
</html>
Let’s deploy the manifest above and verify the status in our cluster:
k get pod
NAME READY STATUS RESTARTS AGE
nginx-deployment-7dc5695798-8xzm7 1/1 Running 0 8m13s
nginx-deployment-7dc5695798-lnmhc 1/1 Running 0 8m13s
nginx-deployment-7dc5695798-mpqnm 1/1 Running 0 8m13s
reloader-reloader-8c4c8b6f9-b2b6g 1/1 Running 0 19m
Verify Operation updating a ConfigMap
After deploying the reloader and annotating your Deployment, update the ConfigMap and observe how ConfigMap Reloader triggers a restart of the associated pods.
Let’s apply a modified version of the configmap:
k apply -f my-configmap-modified.yaml
configmap/my-configmap configured
We can observe that a rolling update has been triggered getting all Pods with the kubectl CLI:
k get pod
NAME READY STATUS RESTARTS AGE
nginx-deployment-6c55697669-jfgg2 0/1 ContainerCreating 0 2s
nginx-deployment-7dc5695798-8xzm7 1/1 Running 0 23m
nginx-deployment-7dc5695798-lnmhc 1/1 Running 0 23m
nginx-deployment-7dc5695798-mpqnm 1/1 Running 0 23m
k get pod
NAME READY STATUS RESTARTS AGE
nginx-deployment-6c55697669-bthxt 0/1 ContainerCreating 0 1s
nginx-deployment-6c55697669-g6rmg 1/1 Running 0 4s
nginx-deployment-6c55697669-jfgg2 1/1 Running 0 7s
nginx-deployment-7dc5695798-lnmhc 1/1 Running 0 23m
Additional
You can also restrict this discovery to only ConfigMap or Secret objects that are tagged with a special annotation. To take advantage of that, annotate your deployments like this:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
annotations:
reloader.stakater.com/search: "true"
The Reloader will trigger the rolling upgrade upon modification of any ConfigMap or Secret annotated like this:
apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
annotations:
reloader.stakater.com/match: "true"
Theoretically we could also restrict the reloading to specific configmaps or secrets by name. However I do not like this approach since it’s more coupled. Moreover, adding a configmap would need adapting the annotation value in the deployment.
Drop me a line if you want to walk through any of these in the context of your specific setup.