Three common methods to achieve ConfigMap hot update: using sidecar, CI script and custom Controller

Table of contents

Method 2: Use CI scripts to implement ConfigMap hot update

Method 3: Use Controller to implement ConfigMap hot update

background

ConfigMap is a resource type used to store configuration information in Kubernetes. In Kubernetes clusters, ConfigMap is widely used to store application configuration information. These configuration information can include environment variables, configuration files, command line parameters, etc. During the running of the application, if the configuration information needs to be updated, the application needs to be restarted. However, in a production environment, restarting the application may cause some impact, so some methods need to be taken to achieve hot update of ConfigMap. This article will introduce three methods to implement ConfigMap hot update, and analyze the advantages and disadvantages of these methods.

Method 1: Use ConfigMap-Reload Sidecar

ConfigMap-Reload Sidecar is a very popular ConfigMap hot update method. The basic idea of this method is to start a Sidecar container in the Pod of the application, which can monitor the changes of the ConfigMap. When the ConfigMap changes, the Sidecar container reloads the configuration information of the application and notifies the application to re-read the configuration information through an HTTP request.

The advantage of ConfigMap-Reload Sidecar is that it is simple to implement and can be quickly deployed in the form of a mirror. In addition, since the Sidecar container and the application container run in the same Pod, they can share the same network and storage volume, so the data transmission speed is fast and it is easy to implement synchronous updates.

However, ConfigMap-Reload Sidecar also has some disadvantages. First, when an environment variable in the ConfigMap changes, the application still needs to be restarted to take effect. Second, since the sidecar container and the application container run in the same Pod, the life cycle between them is also consistent, which may cause unnecessary restarts.

When using the first method, you can use the configmap-reload image of prometheus. Here is an example yaml file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myapp
          env:
            - name: MY_APP_CONFIG
              valueFrom:
                configMapKeyRef:
                  name: myapp-config
                  key: config.yaml
        - name: config-reloader
          image: prometheus-community/configmap-reload:v0.5.0
          args:
            - --webhook-url=http://localhost:5000/-/reload
            - --volume-dir=/etc/config
            - --watched-dir=/etc/config
          volumeMounts:
            - name: config-volume
              mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: myapp-config

In this yaml file, we use two containers: one is our application and the other is the sidecar of configmap-reload. We mount the configuration files in the ConfigMap into the environment variables of the application container, and mount the ConfigMap into the config-reloader container. In the config-reloader container, we specified the watched-dir and volume-dir of the ConfigMap, and specified the webhook-url as localhost:5000/-/reload. When the ConfigMap changes, config-reloader will send a HTTP POST request, which triggers a re-read of the application.

Method 2: Use CI scripts to implement ConfigMap hot update

The second method is to use CI scripts to implement ConfigMap hot update. The basic idea of this method is to calculate the MD5 value of the file in the ConfigMap when the ConfigMap changes, and write it into the Annotation or Label of the Deployment. In this way, at the next deployment, Kubernetes will automatically update the pod in a rolling manner, thereby achieving hot update.

The advantage of this approach is that it is simple to implement and can be deployed automatically through the CI/CD process. In addition, because Kubernetes automatically rolls and updates Pods, manual operations are not required, thus reducing human errors.

However, this method also has some disadvantages. First of all, CI scripts need to be written, the configuration is complex, and certain programming skills are required. Secondly, this method is only applicable to the ConfigMap of the file type. If the configuration information in the ConfigMap is an environment variable or a command line parameter, the application still needs to be restarted to take effect.

In the second approach, we need to write a CI script to automatically update the Pod's annotations or labels. Here is an example script:

#!/bin/bash
set -e

configmap_name=myapp-config
deployment_name=myapp
namespace=default

# Get current deployment image tag
current_image_tag=$(kubectl get deployment $deployment_name -n $namespace -o jsonpath='{.spec.template.spec.containers[0].image}' | cut -d: -f2)

# Get current configmap md5
configmap_md5=$(kubectl get configmap $configmap_name -n $namespace -o jsonpath='{.data.config\.yaml}' | md5sum | cut -d' ' -f1)

# Update deployment image tag and configmap md5 as annotations
kubectl patch deployment $deployment_name -n $namespace -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"configmap-md5\":\"$configmap_md5\"}}},\"spec\":{\"containers\":[{\"name\":\"myapp\",\"image\":\"myapp:$configmap_md5\"}]}}}"

The script will obtain the image tag used by the current Deployment and the MD5 value of the ConfigMap, and then use the kubectl patch command to update the Deployment's comment and container image tag. When the ConfigMap changes, executing this script can automatically update the image tag of the Deployment and the MD5 value of the ConfigMap.

Method 3: Use Controller to implement ConfigMap hot update

The third method is to use Controller to implement ConfigMap hot update.

The basic idea of this method is to write a Controller to realize automatic update by listening to the change event of ConfigMap. When the ConfigMap changes, the Controller will update the annotation or label of the corresponding Pod and trigger the update of the Pod.

Similar to Method 2, the advantage of using Controller to implement ConfigMap hot update is that it has a high degree of automation, does not require manual operations, and can reduce human errors. At the same time, compared with method 1 and method 2, this method is more flexible and can support various types of ConfigMaps, including environment variables, command line parameters, files, etc. In addition, the Controller can also be customized according to different business scenarios to improve flexibility.

However, there are also some disadvantages in using Controller to implement ConfigMap hot update. First of all, compared with method 1 and method 2, the implementation complexity of this method is higher, and the code of the Controller needs to be written, which requires certain development experience. Secondly, since the Controller needs to monitor the ConfigMap change event and update the corresponding Pod, this may increase the load on the cluster and affect the stability of the cluster.

in conclusion

The above three methods can realize the hot update of ConfigMap, and have different advantages and disadvantages. When choosing which method to use, you need to make trade-offs based on specific business scenarios and needs. If you need to implement simple and fast hot updates, you can consider using method 1; if you need automated deployment and rolling updates, you can consider using method 2; if you need more flexibility and customizability, you can consider using method 3.

In practical applications, we can also use some open source projects to realize the hot update of ConfigMap. For example, Reloader is a relatively popular open source project, which can automatically monitor the change event of ConfigMap and trigger the update of the corresponding Pod. ConfigmapController and k8s-trigger-controller are also some optional open source projects, which can be selected and used according to specific needs.

In short, realizing the hot update of ConfigMap is a very important function in Kubernetes. By adopting appropriate methods and tools, the availability and stability of applications can be improved to meet the needs of different business scenarios.