The modifications made to the ConfigMap do not take effect on the active hivemq cluster when utilizing the hivemq operator.

Owned by Sheetal Shet, created
Jul 07, 2023
1 min read

 Problem

If the hivemq cluster is already running and a ConfigMap is updated, the changes do not take effect automatically on the running pods.

 Solution

Updating a ConfigMap in Kubernetes does not automatically apply the changes to running pods. The pods need to be restarted or redeployed for them to pick up the updated ConfigMap changes.

There are a couple of ways to ensure that the pods use the updated ConfigMap:

  1. Restart the pods: You can manually delete and recreate the pods. When the pods are restarted, they will be scheduled on new nodes, and the updated ConfigMap will be mounted into the pods.

  2. Use rolling updates: If you are using a Deployment to manage your pods, you can perform a rolling update. This allows Kubernetes to gradually replace the old pods with new ones, ensuring that your application remains available during the update process. When the new pods are created, they will have the updated ConfigMap.
    Note: This will only work with the Deployment controller type of cluster(Statefulset controller is not supported).
    Here's an example command to perform a rolling update on a Deployment:

    kubectl rollout restart deployment <deployment-name> -n namespace

  3. You can edit values.yaml and make changes for example, adding/removing line breaks in the configOveride section and then using following command to apply those changes.

    helm upgrade --install -f values.yaml <deployment name> hivemq/hivemq-operator -n namespace

By restarting the pods or performing a rolling update, the changes made to the ConfigMap will be reflected in the pods without the need to manually kill or delete the pods.