01 引言
应用部署的一个最佳实践是将应用所需的配置信息与程序分类,就像是微服务Nacos配置中心一样。因此,kubernetes从1.2版本开始就提供了一种统一的应用配置管理方案,也就是本文要讲的ConfigMap。
02 ConfigMap
2.1 ConfigMap概述
ConfigMap以一个或多个key:value
的形式保存在Kubenetes
系统中供应用使用,它既可以表示一个变量的值(例如: apploglevel=info
),也可以用于表示一个完整的配置文件内容(例如:server.xml=<?xml...>...
)。
典型用法如下:
- 生成容器的环境变量;
- 设置容器启动命令的启动参数(需要设置为环境变量);
- 以Volume的形式挂载为容器内部的文件或目录。
2.2 创建ConfigMap资源对象
2.2.1 通过YAML文件方式创建
2.2.1.1 变量
cm-appvars.yaml
展示了将几个应用所需的变量定义为ConfigMap
的用法:
apiVersion: v1
kind: ConfigMap
metadata:
name: cm-appvars
data:
apploglevel: info
appdatadir: /var/data
运行kubectl create
命令创建ConfigMap:
$ kubectl create -f cm-appvars.yarml
查看创建好的ConfigMap:
2.2.1.2 配置文件
接下来,展示将两个配置文件(server.xml
和logging.properties
)定义为ConfigMap的用法,设置key
为配置文件的别名,value则是配置文件的全部文本内容:
运行kubectl create
命令创建该ConfigMap:
查看创建好的ConfigMap:
查看已创建的ConfigMap的详细内容,可以看到两个配置文件的全文:
…
2.2.2 通过kubectl命令行方式创建
2.2.2.1 from-file / from-literal
不使用YAML文件,直接通过 kubectl create configmap
也可以创建ConfigMap,可以使用参数--from-file
或--from-literal
指定的内容,并且可以在一行命令中指定多个参数。
① 通过--from-file
参数从文件中进行创建,可以指定key
的名称,也可以在一个命令行中创建包含多个key的ConfigMap,语法如下:
kubectl create configmap NAME --from-file=[key=]source --from-file=[key=]source
② 通过--from-file
参数在目录下进行创建,该目录下的每个配置文件名都被设置为key
,文件内容被设置为value
,语法如下:
kubectl create configmap NAME --from-file=config-files-dir
③使用--from-literal
时会从文本中进行创建,直接将指定的key#=value#
创建为ConfigMap的内容,语法如下:
kubectl create configmap NAME --from-literal=key1=value1 --from-literal=key2=value2
2.2.2.2 举例
在当前目录下含有配置文件server.xml,可以创建一个包含该文件内容的ConfigMap:
假设在configfiles
目录下包含两个配置文件server.xml
和logging.properties
,创建一个包含这两个文件内容的ConfigMap:
使用--from-literal
来创建:
03 Pod使用ConfigMap
容器应用对ConfigMap的使用有以下两种方法:
-
通过环境变量获取
ConfigMap
中的内容; -
通过
Volume
挂载的方式将ConfigMap
中的内容挂载为容器内部的文件或目录。
3.1 通过环境变量的方式使用ConfigMap
以前面创建的ConfigMap"cm-appvars"为例:
在Pod “cm-test-pod
”的定义中,将ConfigMap “cm-appvars
”中的内容以环境变量(APPLOGLEVEL和APPDATADIR)方式设置为容器内部的环境变量,容器的启动命令将显示这两个环境变量的值(“env|grep APP”):
运行kubectl create -f
命令创建该Pod
,由于是测试Pod
,所以该Pod
在运行完启动命令后将会退出,并且不会被系统自动重启(restartPolicy=Never
):
运行kubectl get pods --show-all
命令查看已经停止的Pod
:
查看该Pod
的日志,可以看到启动命令env|grep APP
的运行结果如下:
这说明容器内部的环境变量使用ConfigMap cm-appvars
中的值进行了正确设置。
Kubenetes
从1.6版本开始引入了一个新的字段envFrom
,实现了在Pod环境中将ConfigMap
(也可用于Secret资源对象)中所定义的key=value
自动生成为环境变量:
通过这个定义,在容器内生成如下环境变量:
3.2 通过volumeMount使用ConfigMap
在如下所示的cm-appconfigfiles.yaml
例子中包含两个配置文件的定义(server.xml
和logging.properties
):
在Pod "cm-test-app"的定义中,将ConfigMap “cm-appconfigfiles”中的内容以文件的形式挂载到容器内部的/configfiles目录下。Pod配置文件cm-test-app.yaml的内容如下:
创建该pod:
登录容器,查看到在/configfiles
目录下存在server.xml
和logging.properties
文件,他们的内容就是ConigMap“cm-appconfigfiles”
中两个key
定义的内容:
如果在引用ConfigMap
是不指定items
,则使用volumeMount
方式在容器内的目录下为每个item
都生成一个文件名为key
的文件。
Pod
配置文件cm-test-app.yaml
的内容如下:
创建该Pod:
登录容器,查看到在/configfiles
目录下存在key-loggingproperties
和key-serverxml
文件,文件的名称来自在ConfigMap cm-appconfigfiles
中定义的两个key
的名称,文件的内容则为value
的内容:
文章来源:https://www.toymoban.com/news/detail-444606.html
04 使用ConfigMap的限制条件
限制条件如下:文章来源地址https://www.toymoban.com/news/detail-444606.html
- ConfigMap必须在Pod之前创建,Pod才能引用它;
- 如果Pod使用envFrom基于ConfigMap定义环境变量,则无效的环境变量名称(例如名称以数字开头)将被忽略,并在事件记录中被记录为InvalidVariableNames。
- ConfigMap受命名空间限制,只有处于相同命名空间中的Pod才可以引用它。
- ConfigMap无法用于静态Pod
到了这里,关于k8s教程(pod篇)-配置管理的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!