K8s ConfigMap配置实战：从创建到挂载环境变量与文件
K8s ConfigMap 配置的核心作用，是把非敏感配置从容器镜像中分离出来，让同一镜像在不同环境复用。
它适合存放配置文件、命令行参数、环境变量等明文数据；
密码、Token 这类敏感信息应交给 Secret，不要写进 ConfigMap。
下面按“先准备、再创建、后挂载、最后验证”的顺序操作，命令和 YAML 都可以直接复制修改。
操作前的环境检查和准备
开始前确认本机已安装 kubectl，并且能正常连接目标集群：
kubectl version --client
kubectl cluster-info
kubectl get nodes如果 cluster-info 报连接失败，先解决 kubeconfig 问题，常见路径是 ~/.kube/config，也可以用 --kubeconfig 指定其他文件。
建议单独建一个测试命名空间，避免影响现有业务：
kubectl create namespace demo-config
kubectl config set-context --current --namespace=demo-config后面的命令默认都在 demo-config 命名空间执行。
创建 ConfigMap 的三种常用方式
第一种是直接用命令行从字面值创建，适合少量键值对：
kubectl create configmap app-config \
--from-literal=APP_ENV=prod \
--from-literal=LOG_LEVEL=info第二种是从文件创建，键名默认是文件名：
kubectl create configmap nginx-config --from-file=./nginx.conf如果希望自定义键名，可以写成 --from-file=nginx.conf=./nginx.conf。
第三种是写 YAML 再应用，适合纳入版本管理：
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
namespace: demo-config
data:
APP_ENV: "prod"
LOG_LEVEL: "info"
application.properties: |
server.port=8080
logging.level.root=INFO保存为 app-config.yaml 后执行：
kubectl apply -f app-config.yaml
kubectl get configmap app-config -o yaml创建完成后，kubectl get configmap 能列出对象，-o yaml 能看到 data 字段内容，说明创建成功。
把配置挂进 Pod：环境变量与文件两种用法
环境变量方式适合单个键值，Pod 启动时读取：
spec:
containers:
- name: demo
image: busybox:1.36
command: ["sh", "-c", "echo $APP_ENV; sleep 3600"]
envFrom:
- configMapRef:
name: app-config也可以只取某个键：
env:
- name: APP_ENV
valueFrom:
configMapKeyRef:
name: app-config
key: APP_ENV文件挂载方式适合完整配置文件。
下面把 application.properties 挂到容器内的 /etc/app/ 目录：
volumeMounts:
- name: app-config-volume
mountPath: /etc/app
readOnly: true
volumes:
- name: app-config-volume
configMap:
name: app-config
items:
- key: application.properties
path: application.properties应用后进入容器检查：
kubectl apply -f pod.yaml
kubectl exec -it demo -- cat /etc/app/application.properties
kubectl exec -it demo -- env | grep APP_ENV如果命令有输出且内容与 ConfigMap 一致，说明挂载生效。
更新配置和热更新的注意点
修改 ConfigMap 有 kubectl edit configmap app-config 和重新 kubectl apply -f 两种方式。
以环境变量注入的配置，Pod 不会自动更新，必须重启或重建 Pod：
kubectl rollout restart deployment/<你的部署名>以文件挂载的 ConfigMap，kubelet 会在一定同步周期后更新容器内文件，但应用是否重新加载取决于程序自身，很多程序需要发送重载信号或重启进程。
另外要注意：subPath 挂载的文件不会随 ConfigMap 更新，需要重建 Pod 才能拿到新内容。
常见报错怎么排查
CreateContainerConfigError 通常表示引用的 ConfigMap 或键不存在。
先用 kubectl describe pod 查看事件，再核对名称和命名空间：
kubectl get configmap -n demo-config
kubectl describe pod -n demo-config 挂载后文件为空，常见原因是 items 里写的 key 在 ConfigMap 中不存在，或者大小写不一致。
用 kubectl get configmap app-config -o jsonpath='{.data}' 确认实际键名。
如果环境变量没生效，检查是用了 envFrom 还是 env，以及变量名是否被容器启动脚本覆盖。
ConfigMap 与 Pod 必须在同一命名空间，跨命名空间引用会失败。
几个容易踩的坑
不要把密钥、证书私钥放进 ConfigMap，它们在 etcd 中是明文存储，权限控制也更弱。
单个 ConfigMap 不建议塞入过多内容，过大对象会影响读取和更新效率，可以按应用或模块拆分。
提交 YAML 到 Git 前检查是否包含生产敏感值，必要时用占位符加外部注入。
删除 ConfigMap 前先确认没有 Pod 在引用，否则重建 Pod 时可能直接失败。
验证配置是否真正生效
最直接的验证分三步：先看对象是否存在，再看容器内实际内容，最后看应用日志是否读取到新值。
kubectl get configmap app-config -o yaml
kubectl exec -it demo -- cat /etc/app/application.properties
kubectl logs demo | tail -n 20三处结果一致，说明 K8s ConfigMap 配置已经正确落地。
后续调整配置时，按“改 ConfigMap、判断注入方式、决定是否重启、再验证”的顺序执行，能减少大部分线上配置不一致问题。
