昨天带着大家一起使用三种方式创建了ConfigMap,今天我就带着大家一起来学习在Pod中使用ConfigMap。
在Pod中使用ConfigMap
1.通过环境变量方式使用ConfigMap
以前面创建的ConfigMap“cm-appenv”为例:根据上图中的部分内容填写下面yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23 1apiVersion: v1
2kind: Pod
3metadata:
4 name: cm-test-pod
5spec:
6 containers:
7 - name: cm-test
8 image: busybox
9 command: [ "/bin/sh", "-c", "env | grep APP" ]
10 env:
11 - name: APPLOGLEVEL # 定义环境变量的名称
12 valueFrom: # key “apploglever”对应的值
13 configMapKeyRef:
14 name: cm-appenv # 环境变量的值取自 cm-appenv
15 key: loglevel # key为 loglever
16 - name: APPDATADIR # 定义环境变量的名称
17 valueFrom: # key “appdatadir”对应的值
18 configMapKeyRef:
19 name: cm-appenv # 环境变量的值取自 cm-appenv
20 key: appdatadir # key为appdatadir
21 restartPolicy: Never
22
23
使用kubectl create -f命令创建该Pod,由于是测试Pod,所以该Pod在执行完启动命令后将会退出,并且不会被系统自动重启(restartPolicy=Never):
状态为Completed ,Pod已经停止了。
查看该Pod的厉害,可以看到启动命令 “env | grep APP”
说明容器内部的环境变量使用ConfigMap cm-appenv中的值进行了正确设置。
envFrom实现了在Pod环境中将ConfigMap(也可用于Secret资源对象)中所有定义的key=value自动生成为环境变量:
1
2
3
4
5
6
7
8
9
10
11
12
13
14 1apiVersion: v1
2kind: Pod
3metadata:
4 name: cm-test-pod3
5spec:
6 containers:
7 - name: cm-test3
8 image: busybox
9 command: [ "/bin/sh", "-c", "env | grep APP" ]
10 envFrom:
11 - configMapRef:
12 name: cm-appenv
13 restartPolicy: Never
14
由于我们是k8s1.14所以没有办法实现,这点大家了解就好了。
需要说明的是,环境变量的名称受POSIX命名规范([a-zA-Z_][a-zA-Z0-9_]*)约束,不能以数字开头。如果包含非法字符,则系统将跳过该条环境变量的创建,并记录一个Event来提示环境变量无法生成,但并不阻止Pod的启动。
2.通过volumeMount使用ConfigMap
在如下所示的cm-appconfigfiles.yaml例子中包含两个配置文件的定义:server.xml和logging.properties。我们上节已经创建了。
在Pod“cm-test-app”的定义中,将ConfigMap“cm-appconfigfiles”中的内容以文件的形式mount到容器内部的/configfiles目录下。Pod配置文件cm-test-app.yaml的内容如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24 1apiVersion: v1
2kind: Pod
3metadata:
4 name: cm-test-app
5spec:
6 containers:
7 - name: cm-test-app
8 image: tomcat
9 ports:
10 - containerPort: 8080
11 volumeMounts:
12 - name: serverxml
13 mountPath: /configfiles
14 volumes:
15 - name: serverxml
16 configMap:
17 name: cm-appconfigfiles
18 items:
19 - key: key-serverxml
20 path: server.xml
21 - key: key-loggingproperties
22 path: logging.properties
23
24
进入容器,查看到在/configfiles目录下存在server.xml和logging.properties文件,它们的内容就是ConfigMap“cm-appconfigfiles”中两个key定义的内容:
如果在引用ConfigMap时不指定items,则使用volumeMount方式在容器内的目录下为每个item都生成一个文件名为key的文件。
实例如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18 1apiVersion: v1
2kind: Pod
3metadata:
4 name: cm-test-app2
5spec:
6 containers:
7 - name: cm-test-app2
8 image: tomcat
9 ports:
10 - containerPort: 8080
11 volumeMounts:
12 - name: serverxml
13 mountPath: /configfiles
14 volumes:
15 - name: serverxml
16 configMap:
17 name: cm-appconfigfiles
18
使用ConfigMap的限制条件
使用ConfigMap的限制条件如下。
◎ ConfigMap必须在Pod之前创建。
◎ ConfigMap受Namespace限制,只有处于相同Namespace中的Pod才可以引用它。
◎ ConfigMap中的配额管理还未能实现。
◎ kubelet只支持可以被API Server管理的Pod使用ConfigMap。kubelet在本Node上通过 –manifest-url或–config自动创建的静态Pod将无法引用ConfigMap。
◎ 在Pod对ConfigMap进行挂载(volumeMount)操作时,在容器内部只能挂载为“目录”,无法挂载为“文件”。在挂载到容器内部后,在目录下将包含ConfigMap定义的每个item,如果在该目录下原来还有其他文件,则容器内的该目录将被挂载的ConfigMap覆盖。如果应用程序需要保留原来的其他文件,则需要进行额外的处理。可以将ConfigMap挂载到容器内部的临时目录,再通过启动脚本将配置文件复制或者链接到(cp或link命令)应用所用的实际配置目录下。
小结:
大家看到这里的时候,大家已经基本掌握了ConfigMap的用法了。
谢谢大家的支持~