Automatically restarting pods when the secret or config map gets updated

[mbencek]

Hello,
Once the configmap or secret gets updated, pods using these don't see the change. After the update, pods need to get restarted/redeployed manually.

What is the best practice to automate this process on OpenShift 4.10?
Marko

[mighty_quinn · Accepted solution]

You can achieve this by adding a trigger section to the DeploymentConfig object, which defines the actions to take when a configmap or secret changes.

Here's an example of how to configure the DeploymentConfig to trigger a rolling deployment when a configmap changes:

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
name: example
spec:
template:
spec:
containers:
- name: example
image: example:latest
env:
- name: CONFIGMAP_RELOAD_INTERVAL
value: "5s"
volumeMounts:
- name: config-volume
mountPath: /config
volumes:
- name: config-volume
configMap:

name: example-config
triggers:
- type: ConfigChange
type: ImageChange
imageChangeParams:
automatic: true
containerNames:
- example

The trigger section defines two types of triggers: ConfigChange and ImageChange. The ConfigChange trigger is responsible for detecting changes in the configmap referenced by the volume, and the ImageChange trigger is responsible for detecting changes in the Docker image.

The CONFIGMAP_RELOAD_INTERVAL environment variable is used to tell the application how often to check for changes in the configmap. In this example, it is set to 5 seconds.

When a change is detected in the configmap or the Docker image, OpenShift will automatically initiate a rolling deployment, which updates the pods one at a time, ensuring that the application remains available during the update.

Some guidance on DeploymentConfig objects is here:

https://docs.openshift.com/container-platform/4.12/applications/deployments/what-deployments-are.htm...

[varun_gada]

Can this also be acheived with deployment and not deployment config?

[alexcorcoles]

This is a fairly common desire, and there are many discussions on this topic. DO280 incidentally touches this topic in chapter 8, section 4; that's a guided exercise about granting applications access to the Kubernetes API; and the example application is https://github.com/stakater/Reloader , which seems to be a common way to have workloads apply configmap/secret updates.

Note that although this is covered by the course, it's presented as an example and is not meant to be an endorsement, nor imply it's best or supported.

[Wasim_Raja]

Thank you for the important information @alexcorcoles