kubernetes基础知识之configmap热更新

kubernetes 进入pod容器：

kubectl exec -it $pod_name -n $namespace_name -- /bin/bash

热更新：

Configmap实现多个不同的挂载的数据一致性，不是通过共享，而是通过注入的方式，这个注入的方式比较像是追加或者替换。configmap内容变化之后，就主动把新的数据重新注入一次。用新的数据去覆盖掉旧版本的数据，叫热更新。

原文件数据发生变化之后，就会用数据把旧版本的数据替换掉，所以会有软链接。

做完configmap挂载之后，会发现挂载的目录下面的数据，是一个在/etc/config/..data目录的软链接。当第一次注入之后，会把数据注入到文件。更新了内容之后，重新注入的时候会注入新的文件，然后把之前的软链接关系清除掉，把新的文件链接到挂载的目录。用的依然是之前的文件名，但是它背后的内容已经发生了改变，而不会在使用的时候受到影响，这就是热更新。

configmap有热更新的特性。

一段nginx的配置文件：

default.conf:

server {

listen 80 default_server;

server_name example.com www.example.com;

location / {

root /usr/local/nginx/html;

index index.html index.htm;

}

}

用文件创建configmap:

kubectl create cm default-nginx --from-file=default.conf

使用deployment控制器的yaml文件创建pod:

apiVersion: v1

kind: Deployment

metadata:

labels:

app: hotupdate-deploy

name: hotupdate-deploy

namespace: default

spec:

replicas: 3

selector:

matchLabels:

app: hotupdate-deploy

template:

metadata:

labels:

app: hotupdate-deploy

spec:

containers:

- image: nginx

imagePullPolicy: Always

volumeMounts:

- name config-volume

mountPath: /etc/nginx/conf.d/

volumes:

- name: config-volume

configMap:

name: default-nginx

可以把configmap注入deployment这个pod控制器创建的3个pod中，变成默认的配置文件。然后再区修改nginx的配置文件，以此确认发生了热更新的关系。

查看configmap:

kubectl get cm -n $namespace_name

把configmap资源对象输出到资源清单文件：

kubectl get cm default-nginx -o yaml

创建deployment控制器，并且把configmap给调用和挂载过去：

kubectl apply -f deployment.yaml

监视pod的变化状态：

kubectl get pod -n $namespace_name -w

这个过程：

1.创建了一个nginx的默认配置文件。

2.把nginx的默认配置文件default.conf保存成了一个configmap。

3.然后写了一个deployment的pod控制器，会去内部的pod去挂载当前的configmap变成我们的配置文件。

4.随后去修改这个configmap配置文件，去看已经挂载的这些pod内部这个配置文件是否会发生变化。如果能发生变化，证明configmap能做到热更新。

5.如果改变了configmap的内容，pod内部已经挂载的configmap配置文件没有发生变化，那么证明configmap不能实现热更新。

进入pod容器内部：

kubectl exec -it $pod_name -n $namespace_name -- /bin/bash

进入容器的/etc/nginx/conf.d/目录下可以看到configmap注入的default.conf配置文件。

写一个死循环：

while true; do cat default.conf; done

while true; do cat default.conf; sleep 2s; done

编辑cm：

kubectl edit cm default-nginx -n $namespace_name

把listen 80 改成8080号端口。

查看configmap的资源清单：

kubectl get cm default-nginx -n $namespace_name -o yaml

Configmap把信息放入到pod里面，并不是以共享的方式，而是以注入的方式，注入是需要时间的。

再次进入pod内部：

kubectl exec -it $pod_name -n $namespace_name

查看配置文件：

cat /etc/nginx/conf.d/default.conf

发现端口已经改变。

configmap热更新是需要时间的，它是需要一点时间去执行的。configmap把信息放入到pod内部，部署以共享的方式，而是以注入的方式。注入需要时间，注入不是瞬时操作，而是需要时间去安排的。因为同时修改大量的pod，那么瞬时压力会很大，所以kubernetes本身会根据负载的压力去调控热更新的阶段。注入是有序地完成，并且基本上会在一两分钟之内完成大部分的替换。

Configmap是具有热更新的特性的。建议在部署服务的时候，把后期可能会修改的配置文件抽象在configmap对象里，然后再挂载回pod内部。这样做的好处是：后续一旦需要修改配置文件，不需要重新封装镜像，不需要去重新编写控制器，只需要通过edit的方式修改configmap对象本身，就可以修改所有的配置文件。

配置文件内部确实发生变化了，需要重启服务，让配置生效。配置文件发生改变了，需要nginx重新加载。如果没有重新加载配置文件，那么不能改变应用的配置。

Nginx没有办法根据配置文件的变化，自动趋向到最新版，这是nginx的问题，不是kubernetes的问题。

很多的应用都支持热更新，也就是当它监测配置文件发生改变后，它会自动趋向到新的版本，比如traefik 这种web server，它就能够自动监控文件的变化，实现最新版本的变化。也就是traefik根本不需要重启，配置文件改完，它就可以生效。

内部封装的nginx不支持热更新，或者监控配置文件的变化自动趋向到新的版本。nginx不支持热更新是nginx软件的原因，而configmap是支持热更新的。

kubernetes官方了解云原生软件的迭代时期，大部分软件还不支持或者不适应云原生，所以提供了一个接口去触发pod的滚动更新。

更新configmap不会触发pod的滚动更新，但是可以通过修改pod annotations的方式强制触发滚动更新。

鼓励的话语：强者，不退缩，更不抱怨。逆境求生，遇强则强！

Tags：yaml map