当前位置：首页 > news >正文

kubernetes configMap 存储

news 来源：原创 2025/9/4 21:08:08

1.模型

首先会在每一个节点上安装一个叫 agent 端 agent 端要做的作用就是监听当前的目标配置中心的配置选项是否发送更新动作如果有的话我的agent 端的话要从远程的配置中心去下载最新的配置文件替换我当前的再去触发nginx实现重载当然对于后期的运维工程师如果想去发布新的版本的话我只需要在配置中心对于的域名下域名服务下去添加最新的 stable 版本那这样的话我们就可以让我们的agent 指向到我们的最新版本再一次的去出发后端真实服务器的更新和重载整个过程是对于我们来说完全是无痕的不需要我们去做任何的动作那这就是我们的configmap的模型

2.注入机制

是注入而不是共享

将文件分发给三台机器是不是有两种考虑

1.挂载形式共享

第一种方式我们从我们的分发的机器上那需要的分发的这个文件我们能不能把它挂载到你可以在这里搭一个NFS通过共享的方式去实现没有问题

2.注入的形式

我们通过注入的方式让数据达到一致比如真的有一个文件发生变化了那我们类似于执行一条指令来比如 catt 1.txt 2.txt 文件用一个新的数据将原来的文件内部去替换掉那这是不是也可以保证我们多个pod之间的文件是一样的这就是让多个不同服务之间的文件达到一致性的两种思想一个是共享一个是注入

3.利弊

当然对于这两种方案啊各有利弊

我们configmap 的机制是通过注入的方式

1.注入的优势

一次注入后，多次读取不在消耗网络 IO

可以分批注入对于网络 IO 的峰值更低

2.注入的劣势

3.共享的优势

4.共享的劣势

每一次在读取文件的时候，都会发生网络IO

对于共享的io同时去向我们的共享服务器读取这个配置文件那就可能产生峰值的网络IO 的出现

5.总结

共享适合那种有好多不同的小文件我一起共享给你你用哪一个我读取哪一个

那注入的话更适用于那种一两个配置文件而且大概率回去使用它那这时候就用注入

3.创建

这里没有提到 --from-env-file, 建议同学们延展了解下 --from-file 和 --from-env-file 的区别

1.--from-file 文件名为 key 文件内容为 value

kubectl create configmap 对象名 --from-file=文件路径

1.文件内部必须是一行一对的 k=v,可以在使用的适合注入至pod的内部变成环境变量

1.txt

name=zhangsan

passwd=123

2.文件内部不是一行一对的k=v 不能被当作环境变量使用

2.txt

今天天气真不错，适合爬山

2.--from-literal 我们直接把对应需要去创建出来的key value 对象直接编写在了我们的选项中或者创建命令里所以这种方式更适合那种key value比较简短的比如就写一个用户名

kubectl create configmap literal-config --from-literal=name=dave --from-literal=password=pass

3.使用第一种方式创建

1.创建一个jmj.txt文件文件名随便取

文件内容

name=zhangsan
password=123456

执行

kubectl create configmap jmj-config --from-file=jmj.file

创建成功

查看一下

kubectl get configmap

简写

kubectl get cm

获取对象里面的信息

kubectl get cm jmj-config -o yaml

建议用文件的方式创建

如果你想把 jmj-config 打出 yaml 可以执行

kubectl create configmap jmj-config --from-file=jmj.file --dry-run -o yaml > 2.cm.yaml

1..另一种查看方式

kubectl describe cm jmj-config

4.使用第二种方式创建

kubectl create configmap literal-config --from-literal=name=dave --from-literal=password=pass

这样创建两个文件里面分别是 dave 和 pass 然后执行下面的命令和上面那条命令是一个效果

kubectl create configmap aa-config --from-file=name --from-file=password

5.yaml

可以通过yaml创建

6.小实验将当前的configmap 注入到pod内部环境变量

创建 1.pod.yaml

apiVersion: v1
kind: ConfigMap
metadata:name: literal-confignamespace: default
data:name: davepassword: pass
---
apiVersion: v1
kind: ConfigMap
metadata:name: env-confignamespace: default
data:log_level: INFO
---
apiVersion: v1
kind: Pod
metadata:name: cm-env-pod
spec:containers:- name: myapp-containerimage: wangyanglinux/myapp:v1.0command: [ "/bin/sh", "-c", "env" ]env:- name: USERNAMEvalueFrom:configMapKeyRef:name: literal-configkey: name- name: PASSWORDvalueFrom:configMapKeyRef:name: literal-configkey: passwordenvFrom:- configMapRef:name: env-configrestartPolicy: Never

env加入环境变量来源于某个 configmap name 为 cm 名称 key 为 key

envFrom 直接把这个configmap的所有key value 注入到环境变量但是不能修改了

kubectl create -f 1.pod.yaml

看一下pod的日志

 kubectl logs cm-env-pod

7.小实验将当前的configmap 注入到 mainC的启动命令

configmap可以当做启动参数

创建 2.pod.yaml

apiVersion: v1
kind: Pod
metadata:name: cm-command-pod
spec:containers:- name: myapp-containerimage: wangyanglinux/myapp:v1.0command: [ "/bin/sh", "-c", "echo $(USERNAME) $(PASSWORD)" ]env:- name: USERNAMEvalueFrom:configMapKeyRef:name: literal-configkey: name- name: PASSWORDvalueFrom:configMapKeyRef:name: literal-configkey: passwordrestartPolicy: Never

kubectl create -f 2.pod.yaml

8.小实验将当前 Configmap 变成我们的文件去使用

创建 3.pod.yaml

apiVersion: v1
kind: Pod
metadata:name: cm-volume-pod
spec:containers:- name: myapp-containerimage: wangyanglinux/myapp:v1.0volumeMounts:- name: config-volumemountPath: /etc/configvolumes:- name: config-volumeconfigMap:name: literal-configrestartPolicy: Never

创建一个卷卷名叫 config-volume 挂载到当前容器的 /etc/config

kubectl create -f 3.pod.yaml

进入容器内部查看

kubectl exec -it cm-volume-pod -- /bin/bash

为什么它是蓝色的呢

他不是文件而是链接

牵扯到热更新

1.什么是热更新呢

我挂载以后后续我的原文件发送变化，我都会把帮你把所有的现在老版本的给替换掉这就是为什么要做链接的原因

当我第一次注入的时候这是原文件我做一个链接链接到你的文件上了如果我要去进行热更新了换了一个内容那我注入到第二个文件里再把第一个链接关系清除再把第二个文件链接到这个文件名上你依然用的是这个文件名但是很显然它的背后发生了变化而不会在你使用的时候影响你这就是为什么要做链接的原因

2.创建 nginx 默认 default.conf文件

server {listen 80 default_server;server_name example.com www.example.com;location / {root   /usr/share/nginx/html;index index.html index.htm;}
}

3.将default.conf 配置文件转化为 configmap对象

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

4.将 configmap对象输出为 yaml形式

kubectl get cm default-nginx -o yaml

5.创建一个deployment 控制器

apiVersion: apps/v1
kind: Deployment
metadata:labels:app: hotupdate-deployname: hotupdate-deploy
spec:replicas: 5selector:matchLabels:app: hotupdate-deploytemplate:metadata:labels:app: hotupdate-deployspec:containers:- image: nginxname: nginxvolumeMounts:- name: config-volumemountPath: /etc/nginx/conf.d/volumes:- name: config-volumeconfigMap:name: default-nginx

kubectl apply -f deployment.yaml

6.进入一个pod里

kubectl exec -it pod名 -- /bin/bash

循环查看 default.conf

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

7.开启另一个终端修改configmap对象里的 default.conf

kubectl edit cm default-nginx

改成8080

esc wq 保存退出

kubectl get  cm default-nginx -o yaml

8.回到之前那个终端

发现配置文件已经改变了

kubernetes会根据服务器的压力自己去调控注入的阶段什么时候注入第一个我们会有序的执行基本会在一两分钟内完成大部分的替换是没有任何问题的那从这里我们可以看到这就是热更新的一种标学

所以在后面我们部署服务的时候我们都建议大家把可能会后期修改的配置文件抽象在 configmap对象里然后在挂载回我们pod内部这样做的好处就是一旦后续我们需要修改的时候我不需要重新封装镜像我不需要去重新写控制器我只需要通过edit 等方式修改configmap 对象本身就可以修改所有的配置文件

9.还有一个问题文件内部发生变化了但是nginx 没有读取变化的配置

默认能够访问到80端口

nginx不支持热更新配置文件

比如有 traefik web 服务器支持监听配置文件热更新根本不需要重启，你改配置文件改完以后就生效了就这么简单所以说不是这个机制不好用而是我们现在内部封装的这个nginx 有点太老了不支持我们所谓的热更新或者监控文件变化自动趋向到新版

官方为了解决这个问题推出了改变pod annotations的方式让他强制滚动更新

patch命令

kubectl patch deployment hotupdate-deploy --patch '{"spec":{"template":{"metadata":{"annotations":{"version/config":"666666666"}}}}}'

因为完全可以放入脚本里去执行，不想我们的edit我们是一种交互的方式

edit命令修改

kubectl edit deployment hotupdate-deploy

修改

esc wq保存退出

滚动更新中

在annotations下，随便打出任意字符的键值对都可以触发滚动更新，比如helloworld：“12345”一样可以触发，原来应该是，只要打的补丁能使资源清单发生变化，都能触发更新

这里再插入一个小知识点

因为镜像加载默认是 always 就是如果你的镜像是 latest 默认就回去远程拉取镜像然后在启动

你可以把当前镜像下载策略改成如果有就不下载

提醒

使用该configmap挂载的env环境变量的方式，那么修改configmap原对象是环境变量并不会发生改变

使用该configmap 挂载的Volume 中的数据需要一段时间（实测大概10秒）才能同步更新

然后就改不了了而且是不可逆的

要想再改回去只能把configmap 这个对象删除