第七章.k8s存储-configmap-2

来源链接：https://www.bilibili.com/video/BV1PbeueyE8V?spm_id_from=333.788.videopod.episodes&vd_source=0e85828f19fba96334ebaebea2da3e2f&p=43

第七章 k8s存储 - ConfigMap 实践笔记（视频P43）

一、多资源对象YAML合并规则

Kubernetes支持将多个资源对象定义在同一个YAML文件中，不同资源对象之间通过三个顶头书写的横杠---分隔，不可多写、少写或修改格式，否则会导致解析错误。

二、ConfigMap三种使用方式

1. 注入为容器环境变量

• 实现原理：通过Pod的env字段，引用ConfigMap的key值，将ConfigMap的数据注入为容器的环境变量，容器启动时可直接调用该变量。
• 操作验证流程：
  1. 提前创建包含name、password、log_level等字段的ConfigMap（名称为literal-config）
  2. 编写Pod YAML，通过env.valueFrom.configMapKeyRef字段关联对应ConfigMap的key，完成环境变量注入，重启策略设置为Never
  3. 执行kubectl create -f pod.yaml创建Pod，若提示ConfigMap已存在可忽略（为之前实验遗留资源）
  4. 查看Pod状态为Completed，执行kubectl logs <pod名称>查看日志，可确认环境变量已成功注入，输出内容包含ConfigMap对应的key值

2. 作为Pod启动命令的参数

• 实现原理：与方式1底层逻辑一致，先将ConfigMap数据注入为环境变量，再将环境变量作为容器启动命令的一部分直接调用，适用于启动命令需要动态获取配置的场景。
• 操作验证流程：
  1. 编写Pod YAML，将容器默认启动命令替换为echo $(your_name) $(password)，同时通过env字段引用ConfigMap的key注入为环境变量，重启策略设置为Never
  2. 执行kubectl create -f pod.yaml创建Pod，Pod状态变为Completed
  3. 执行kubectl logs <pod名称>，输出结果为david pass，验证启动命令成功调用了ConfigMap注入的环境变量

3. 挂载为容器内文件

• 前置说明：创建ConfigMap时使用--from-file参数，会将文件名转为ConfigMap的key，文件内容转为value；挂载为文件时是反向操作，ConfigMap的key转为容器内的文件名，value转为文件内容。
• 核心配置说明：
  • Volume是脱离容器生命周期的存储方式，卷挂载用于将存储卷关联到容器的指定目录
  • volumes字段：声明卷，指定卷的数据源为ConfigMap，关联对应的ConfigMap名称
  • volumeMounts字段：声明卷挂载规则，指定卷名称、挂载到容器的目标目录
• 操作验证流程：
  1. 编写Pod YAML，通过volumes字段关联literal-config ConfigMap，通过volumeMounts字段将卷挂载到容器的/etc/config目录，重启策略设置为Never
  2. 执行kubectl create -f pod.yaml创建Pod，Pod状态为Running
  3. 执行kubectl exec -it <pod名称> -- /bin/sh进入容器，执行ls /etc/config可看到ConfigMap的key对应的两个文件（name、password）
  4. 查看文件内容：cat name输出DAVID，cat password输出pass，内容与ConfigMap一致；文件默认不会添加换行符，输出时可能拼接在一行，属于正常现象
• 特殊说明：挂载的文件实际为软链接，链接到kubelet管理的对应Configmap存储路径，这是为了实现热更新特性

三、ConfigMap热更新机制

• 背景：ConfigMap是注入式更新，首次挂载后若直接修改ConfigMap，已运行的Pod内的挂载内容不会自动更新，无法实现多Pod配置一致性
• 热更新原理：
  1. 首次挂载ConfigMap时，kubelet将ConfigMap数据注入为临时文件，再创建软链接指向容器内挂载的目标文件名
  2. 当ConfigMap内容发生变更时，kubelet会生成新的临时文件存储更新后的内容，再将软链接指向新的临时文件
  3. 容器内访问目标文件名时，实际通过软链接获取最新内容，且更新过程中不会影响正在使用文件的进程，避免文件损坏
• 热更新验证实验：
  1. 编写Nginx默认配置文件default.conf，内容包含监听端口、默认服务匹配规则、根路径、主页名称等标准配置
  2. 执行kubectl create cm default-nginx --from-file=default.conf将配置文件转为ConfigMap
  3. 编写Deployment YAML，配置5个副本，通过Volume挂载该ConfigMap到容器的/etc/nginx/conf.d目录，镜像使用Nginx官方rpm包镜像
  4. 执行kubectl apply -f deployment.yaml创建Deployment，等待Pod全部启动完成
  5. 修改ConfigMap的内容（如调整监听端口），观察Pod内的/etc/nginx/conf.d/default.conf内容是否同步更新，验证热更新生效

四、实验注意事项

• 多资源对象合并时，分隔符---必须严格顶头书写，不可额外添加空格或修改数量
• 若创建Pod时提示ConfigMap已存在，无需删除，直接继续后续操作即可
• 挂载ConfigMap为文件时，文件内容默认不会添加换行符，输出时可能拼接在一行，属于正常现象
• 热更新实验中需注意镜像与配置路径的匹配，避免因路径错误导致配置不生效

AI 总结

本部分内容围绕Kubernetes ConfigMap的实践应用展开，依次讲解了ConfigMap注入为环境变量、作为启动参数、挂载为文件的三种使用方式的实现原理与操作验证，深入剖析了ConfigMap热更新的底层逻辑与实验方法，帮助掌握ConfigMap在Pod中的实际应用场景与配置动态更新的实现机制，是K8s存储模块的核心实践内容。