Kubernetes 配置管理
目录
(6）多次使用使用--from-file 传入参数，用以从多个文件创建 configMap
(3)使用valueFrom从 ConfigMap 中定义变量
(4)编写文件，将名为 spec-config的 ConfigMap 挂载到容器的/etc/config 目录下
一：什么是ConfigMap
在传统架构中，配置文件往往被保存在宿主机上，程序启动是可以指定某个配置文件，但是使用容器部署时，容器所在的节点并不固定，所以不能使用这种方式，此处在构建镜像时，如果把配置文件也放在容器里面，那么配置文件一旦有更改的话，也是一件非常麻烦的事情。所以 k8s 抽象了一个 ConfigMap的概念，将配置与 pod 和组件分开，这有助于保持工作负载的可移植性，使配置更易于更改和管理。比如在生产环境中，可以将 Nginx、Redis 等应用的配置文件存储在 ConfigMap 上，然后将其挂载即可使用。
相对于 secret，configMap 更倾向于存储和共享非敏感、未加密的配置信息，假如是集群中使用敏感信息，最好使用 secret。
ConfigMap 用来在键值对数据库(etcd)中保存非加密数据。一般用来保存配置文件。
ConfigMap 可以用作环境变量、命令行参数或者存储卷。
ConfigMap 将环境配置信息与 容器镜像 解耦，便于配置的修改。
ConfigMap 在设计上不是用来保存大量数据的。
ConfigMap 中保存的数据不可超过 1 MiB。
二:创建 ConfigMap
| 数据源类型 | 命令格式 | 说明 | 示例 |
|---|---|---|---|
| 字面值（Literal） | kubectl create configmap <map-name> --from-literal=<key>=<value> | 直接通过命令行指定键值对，适合简单配置。 | kubectl create configmap app-config --from-literal=log_level=debug |
| 单个文件 | kubectl create configmap <map-name> --from-file=<path-to-file> | 将文件内容作为值，键默认为文件名（可自定义）。 | kubectl create configmap nginx-config --from-file=nginx.conf |
| 目录 | kubectl create configmap <map-name> --from-file=<path-to-directory> | 将目录下所有文件合并为一个 ConfigMap，键为文件名，值为文件内容。 | kubectl create configmap app-files --from-file=./configs/ |
| 多文件或混合 | kubectl create configmap <map-name> --from-file=<key1>=<file1> --from-literal=<key2>=<value2> | 支持混合使用文件和字面值，灵活生成复杂配置。 | kubectl create configmap global-config --from-file=db.properties --from-literal=env=prod |
1:基于目录创建 ConfigMap
假如一次性需要多个文件来创建 ConfigMap，可以使用 kubectl create configmap 命令从同一个目录中的多个文件创建 configMap。
(1)创建 conf 目录，里面放置两个文件
(2)基于目录下的所有文件创建 ConfigMap
注意:
ConfigMap 是按namespace 隔离的，不同的namespace 之间的configMap 的名称可以相同，但是不能跨namespace 进行访问，创建ConfigMap 时，可以使用-n 选项指定资源所在的namespace。
(3)查看当前创建的 ConfigMap
注意:
由于该 configMap 是直接基于目录创建的，没有指定 ConfigMap 中的 key 名，因此默认是按照目录下的文件名作为 ConfigMap 数据中的 key 名。
2:基于文件创建 configMap
(1)创建测试文件 game-cfg
(2)基于单个文件创建 configMap
(3)查看当前创建的 ConfigMap
注意:
由于没有指定 ConfigMap 的 key，因此使用文件名作为 key.
(4)使用带有 key 的命令创建 ConfigMap
(5)查看当前创建的 ConfigMap
（6）多次使用使用--from-file 传入参数，用以从多个文件创建 configMap
3:基于 ENV 文件创建 configMap
假如有一个文件 game-env-file.cfg，里面存储的 key=value 形式的数据，此类文件可以当做某个应用的环境变量配置，此时可以使用--from-env-file 从 ENV 文件创建 ConfigMap。
(1)创建测试用的 key-value 文件
(2)创建ConfigMap
(3)查看当前创建的 ConfigMap
4:基于字符值创建 ConfigMap
有时候配置的并不是很多，只有几个 key=value 的参数，可以直接使用 kubectl create configmap--from-lietal 参数来定义命令行的字符值。
备注:
lietal:文字的;逐字的;
(1)利用字符值创建 configMap
例如有字符值:spec.level=info和spec.type=charm
(2)查看当前configMap
5：删除已创建的 ConfigMap
注意:
删除时只需指定要删除的 ConfigMap 的名称
四:configMap实践
本实践案例将 CM 创建的变量引入到 pod 内。
在 kubernetes 中，用户可以使用环境变量引用 configMap 中的数据，当容器启动时，kubernetes会将 ConfigMap 数据作为环境变量注入到容器的进程中。为了使用 ConfigMap 中的数据,用户需要在 pod的规范(spec)中定义一个env 字段，并指定 ConfigMap 中的“键值对”
1:使用 valueFrom 定义容器的环境变量
(1)先以字符值的形式创建 configMap
(2)查看创建的 ConfigMap
(3)使用valueFrom从 ConfigMap 中定义变量
| ConfigMap 中的键 (Key) | Pod 中环境变量定义 | 说明 |
|---|---|---|
name1 | name: my-name01valueFrom.configMapKeyRef.name: cm-namevalueFrom.configMapKeyRef.key: name1 | 将 ConfigMap (cm-name) 中的键 name1 的值注入到 Pod 的环境变量 my-name01。 |
log_level | name: LOG_LEVELvalueFrom.configMapKeyRef.name: app-configvalueFrom.configMapKeyRef.key: log_level | 将 ConfigMap (app-config) 的 log_level 映射为 Pod 的 LOG_LEVEL。 |
(4)创建此 pod
(5)查看 pod 日志
2:使用 envFrom 定义容器的环境变量
k8s 从 1.6的版本开始，引入了一个新的字段 envFrom，实现了在 Pod 中将 ConfigMap 中所有定义的key=value 自动生成为环境变量。使用 envFrom 时，环境变量的名字是 configMap 中数据的 key 名。
| 特性 | envFrom | valueFrom |
|---|---|---|
| 功能 | 自动将 ConfigMap/Secret 中的所有键值对注入为 Pod 的环境变量。 | 手动指定 ConfigMap/Secret 中的单个键值对注入为 Pod 的环境变量。 |
| 环境变量名 | 与 ConfigMap/Secret 中的键名完全相同。 | 可自定义环境变量名（无需与源键名相同）。 |
| 使用场景 | 需要批量导入所有配置项（如全局环境变量）。 | 需要选择性导入或重命名配置项（如敏感键名映射为其他变量名）。 |
| YAML 示例 | yaml envFrom: - configMapRef: name: cm-name | yaml env: - name: CUSTOM_NAME valueFrom: configMapKeyRef: name: cm-name key: original-key |
| 注意事项 | 若 ConfigMap 中的键名不合法（如含破折号），会被自动跳过（K8s 1.28+ 会报错）。 | 需确保引用的键名在 ConfigMap 中存在，否则 Pod 启动失败。 |
-
envFrom：-
批量导入：适合无需重命名、键名合法的场景（如
DB_HOST=db.example.com）。 -
简单高效：一行配置即可注入全部键值对。
-
-
valueFrom：-
精细控制：适合需要重命名或选择性导入的场景（如将
cm-db-url映射为DATABASE_URL）。 -
灵活性高：可混合使用多个 ConfigMap/Secret 的键值。
-
使用建议：
-
合规键名：ConfigMap 的键名需符合环境变量命名规则（如仅使用
[A-Za-z0-9_]）。 -
混合使用：可在同一个 Pod 中同时使用
envFrom和valueFrom以满足不同需求。
(1)使用envFrom从 ConfigMap 中定义变量
(2)创建此 pod
(3)查看 pod 的日志
3:以文件的形式挂载 configMap
大部分情况下，ConfigMap 定义的都是配置文件，而不是环境变量，因此需要将 ConfigMap 的文件挂载到 Pod 中，然后 Pod 中的容器就可以引用，此时可以通过 Pod 的 volume 字段进行挂载。
(1)创建测试文件
(2)使用带有 key 的命令创建 configMap
(3)查看configMap
(4)编写文件，将名为 spec-config的 ConfigMap 挂载到容器的/etc/config 目录下
(5)创建此 Pod
注意:
容器的/etc/config 目录会被覆盖掉
(6)查看创建结果
(7)登录容器，查看挂载情况
（8）删除此 Pod
4:自定义文件名挂载 configMap
很多情况下，需要更改挂载的文件名，可以使用 path 字段指定 ConfigMap 挂载的文件名，比如将文件 app2.conf 挂载到/etc/conf下，并重命名为 app2.cfg。
(1)编写 Pod 文件
(2)创建此 Pod
(3)查看创建结果
(4)登录容器查看挂载结果
(5)删除此Pod
5:指定挂载的文件权限
(1)编写 Pod 文件，指定文件权限
备注:
defaultMode: 0666 没有设置权限的其他文件默认的权限
(2)创建此 Pod
(3)查看创建结果
(4)登录容器查看挂载结果
(5)删除此Pod 和ConfigMap
6:利用 subPath 解决挂载覆盖的问题
当挂载 ConfigMap 或 Secret 到容器内部时，会覆盖容器中的目录，也就是是说，在容器中的对应的目录中，就只剩下我们挂载进去的文件，此目录中其他的文件都会丢失。从而导致容器无法正常运行。为了解决挂载覆盖的问题，需要使用 SubPath 的方式进行挂载
(1)创建测试用的配置文件
(2)使用带有 key 的命令创建 configMap
(3)查看configMap
(4)创建 Pod 文件，挂载文件
| 字段 | 说明 | 示例值 | 注意事项 |
|---|---|---|---|
mountPath | 指定容器内目标目录的路径，ConfigMap 内容将挂载到该目录下。 | /etc/nginx/conf | 若目录已存在文件，挂载后会被覆盖（除非使用 subPath）。 |
subPath | 仅挂载 ConfigMap 中指定的键（文件），而非整个 ConfigMap。 | nginx.conf | 使用 subPath 时，其他文件不会被挂载，避免覆盖目录原有内容。 |
items | 定义 ConfigMap 中键值对到容器内文件的映射规则（需配合 subPath 使用）。 | key: nginx.confpath: nginx.conf | 若不指定 items，ConfigMap 中所有键会以文件名形式出现在 mountPath 目录下。 |
key | ConfigMap 中的键名（文件名）。 | nginx.conf | 键名必须与 ConfigMap 中定义的键完全一致。 |
path | 容器内文件的路径及名称（相对于 mountPath）。 | nginx.conf 或 subdir/config.txt | 可嵌套子目录（如 path: conf.d/nginx.conf），但需确保父目录存在。 |
| 场景 | 是否使用 subPath | 效果 |
|---|---|---|
| 挂载整个 ConfigMap | 否 | mountPath 目录下会生成所有键对应的文件（可能覆盖原有文件）。 |
| 仅挂载单个文件 | 是 | 只有指定键的文件出现在 mountPath 中，目录其他文件不受影响。 |
(5)创建此 Pod
(6)查看创建结果
(7)登录容器查看挂载结果
(5)删除此Pod
五:ConfigMap 限制
ConfigMap 在使用时有很多的限制，如果没有正确使用 ConfigMap，可能会导致 Pod 不能正常操作,目前具有的限制如下:
1:必须创建 ConfigMap 才能在 Pod 中引用它，如果 Pod 引用的 configMap 不存在，Pod 将无法启动一直处于 Pending 状态，可以通过 describe 命令査看
2:Pod 引用的键必须存在于 configMap 中，否则 Pod 无法启动，一直处于 ContainerCreating 状态，可以通过 describe 命令查看查看。
3:使用 envFrom 配置容器环境变量时，默认会跳过被视为无效的键，但是不影响 Pod 的启动，无效的变量会记录在事件日志中。
4：ConfigMap 和引用它的 Pod 需要在同一个命名空间。
5:configMap 中保存的数据不可超过1 MiB。
六:加密数据管理
上一节讲解的 ConfigMap 主要用于非安全的数据，与其对应的是 Secret 对象类型，用来保存敏感信息，例如密码、令牌或 SSH Key，将这些信息放在 Serret 中比较安全和灵活。用户可以创建 Secret 并日引用到 Pod 中，比如使用 secre 初始化 Redres、MySOL 密码等。
1:创建 secret
创建 Secret 的方式有很多，可以使用命令行工具 Kubectl 或通过 yam1 文件创建。
(1)使用kubectl命令行创建 secret
假设有些 Pod 需要访问数据库，可以将账户、密码存储在 username.txt 和 password.txt 文件中，然后以文件的形式创建 secret 供 Pod 使用。
首先创建账户信息:
以文件 username.txt 和 password.txt 创建 Secret，创建方式和 configMap 一致:
备注:
generic:通用类型
db-user-pass:创建的secret的名字
查看 Secret:
备注:
Opaque 不透明的，表示 secret 是加密的形式保存数据的
默认情况下，get 和 describe 命令都不会显示文件的内容，这是为了防止 secret 中的内容被意外暴露。所以，显示出来的信息中 Data 字段没有对应的值，只显示了文件的名字。
(2)通过 yaml 文件创建 secret
手动创建 Secret 时，每一项内容必须是 base64 编码的，所以要先对明文进行编码:
然后创建一个 yaml 文件，格式如下:
备注:
0paque:不透明的
最后使用该文件创建一个 Secret:
2:解码 secret
3:在pod中应用secret
secret 和 ConfigMap 的用法类似，也可以作为数据卷挂载，或作为环境变量以供 Pod 的容器使用。
和 ConfigMap 一样，可以在 Pod 的 volume 中使用 Secret:
査看 Pod 中的信息
开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。
更多推荐
19
0- 0
已为社区贡献1条内容
所有评论(0)