Why do some configMap require restarting the Pod to take effect?

In general application deployment, programs and configuration information are separated to ensure that programs can be reused in various environments.

In the container scenario, after the application is packaged into an image, the configuration can be injected into the container when creating the container through environment variables or file mounting.

In the Kubernetes scenario, configMap is used to separate applications and configurations. There are many ways to use configMap. Some methods modify the configuration of configMap and it will take effect without restarting the Pod. Some methods require restarting the Pod to take effect. See which one you use.

1. How to use

If you use configMap to separate programs and configurations, you must first define configMap and then deploy configMap.

1.1 Define configMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: democm
  namespace: demo
data:
  db_name: demodb
  db_host: 172.19.132.23

configMap has 3 types of usage: env方式 , envFrom方式 , volumes方式.

1.2 env method

This method is to inject the key-value of configMap into the environment variable of the container. When used in the program, the corresponding value can be obtained by using the name defined in env. How to use it:

apiVersion: v1
kind: Pod
metadata:
  name: pod-cm-1
  namespace: demo
  labels:
    app: pod-cm-1
spec:
  containers:
    - name: pod-cm-1
      image: busybox
      imagePullPolicy: IfNotPresent
      tty: true
      # 会出现在容器的环境变量里,程序里要使用env#name可以获取到对应的值
      env:
        - name: db_name_app
          valueFrom:
            configMapKeyRef:
              name: democm
              key: db_name
        - name: db_host_app
          valueFrom:
            configMapKeyRef:
              name: democm
              key: db_host

1.3 envFrom method

This method also injects the key-value of configMap into the environment variable of the container. The usage method is similar to env方式, except that when the program is used, it is directly defined using configMap. key, you can get the corresponding value. Here's how to use it:

apiVersion: v1
kind: Pod
metadata:
  name: pod-cm-2
  namespace: demo
  labels:
    app: pod-cm-2
spec:
  containers:
    - name: pod-cm-2
      image: busybox
      imagePullPolicy: IfNotPresent
      tty: true
      # 程序里使用configmap的key
      envFrom:
        - configMapRef:
            name: democm

1.4 volumes mode

This method uses volume mounting to write the key-value of configMap into the file. The key is the file name and the value is the file content.

Use as follows:

apiVersion: v1
kind: Pod
metadata:
  name: pod-cm-3
  namespace: demo
  labels:
    app: pod-cm-3
spec:
  nodeName: k8s-worker-2
  containers:
    - name: pod-cm-3
      image: nginx
      imagePullPolicy: IfNotPresent
      ports:
        - containerPort: 80
          hostPort: 8080
      volumeMounts:
        - name: workdir
          mountPath: /usr/share/nginx/html
  volumes:
    - name: workdir
      configMap:
        name: democm
        optional: true

Observe the contents under the volume volume:

Enter the container's/usr/share/nginx/html directory, you can see that the key-value defined by configMap will appear in this directory, and there will be a file similar to the time. Enter the folder and you can see the corresponding db_host and db_name files.

If the configMap changes, a new file will be generated accordingly.

2. Practice

2.1 Orchestration and deployment configMap

Arrange and deploy configMap and view the configMap information after deployment

[root@k8s-master configmap]# kubectl apply -f configmap.yaml
configmap/democm created
[root@k8s-master configmap]# kubectl get cm -n demo
NAME     DATA   AGE
democm   2      11s
[root@k8s-master configmap]# kubectl describe cm democm -n demo
Name:         democm
Namespace:    demo
Labels:       <none>
Annotations:  <none>

Data
====
db_host:
----
172.19.132.23
db_name:
----
demodb
Events:  <none>

2.2 env method

You can see from here that the env in the yaml defined by env方式 has been put into the environment variable of the container, but the value in env is taken from the configMap.

[root@k8s-master configmap]# kubectl exec -it pod-cm-1 -n demo -- /bin/sh
/ #
/ # evn
/bin/sh: evn: not found
/ # env
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_SERVICE_PORT=443
HOSTNAME=pod-cm-1
SHLVL=1
HOME=/root
TERM=xterm
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
db_host_app=172.19.132.23
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_HOST=10.96.0.1
PWD=/
db_name_app=demodb

2.3 envFrom method

You can see from hereenvFrom方式 directly puts the key-value of configMap into the environment variable of the container.

[root@k8s-master configmap]# kubectl apply -f pod_configmap_2.yaml
pod/pod-cm-2 created
[root@k8s-master configmap]# kubectl exec -it pod-cm-2 -n demo -- /bin/sh
/ #
/ # env
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.96.0.1:443
HOSTNAME=pod-cm-2
SHLVL=1
HOME=/root
db_name=demodb
TERM=xterm
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_HOST=10.96.0.1
PWD=/
db_host=172.19.132.23

2.4 volumes mode

You can see in this way that volumes方式 does not put the value of configMap into the environment variable.

[root@k8s-master configmap]# kubectl apply -f pod_configmap_3.yaml
pod/pod-cm-3 created
[root@k8s-master configmap]# kubectl exec -it pod-cm-3 -n demo -- /bin/sh
# env
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.96.0.1:443
HOSTNAME=pod-cm-3
HOME=/root
PKG_RELEASE=1~bookworm
TERM=xterm
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
NGINX_VERSION=1.25.2
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
KUBERNETES_PORT_443_TCP_PORT=443
NJS_VERSION=0.8.0
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_HOST=10.96.0.1
PWD=/

But you can see that the key-value of configMap is written to the file.

# cd /usr/share/nginx/html
# ls
db_host  db_name
# cat db_host
172.19.132.23
# cat db_name
demodb

2.5 Modify configMap value

Modify the configMap value, then redeploy the configMap, and continue to observe these three methods.

Use the commandkubectl exec -it pod-cm-xxxxxx -n demo -- /bin/sh to enter the container, you can observe:

  • env方式The values ​​corresponding to the and envFrom方式 modes have not changed and will take effect after restarting the Pod.

  • volumes方式The value will change automatically.

3. Summary

  • This article summarizes three ways to use configMap: env方式, envFrom方式, volumes方式.

  • env方式To put it bluntly, the and envFrom方式 methods inject environment variables into the container. When the container starts, they have already been injected and cannot be modified. Every time you modify the key-value of configMap, you need to restart the Pod to take effect.

  • volumes方式In this way, the key-value of configMap is actually written to the volume volume corresponding to the container, and every time the configMap changes, the latest value will be written to the volume volume, so that the container can get the latest value every time.

Guess you like

Origin blog.csdn.net/zfw_666666/article/details/134580105