Docker 与 K8S学习笔记(十九)—— Pod的配置管理
admin
撰写于 2022年 01月 22 日

我们在部署应用时常常会考虑将应用程序与配置文件相分离,这样可以使应用程序更好的复用,并且通过不同配置也能实现更灵活的功能。将应用制作成镜像后,我们可以在启动容器时通过环境变量或挂载文件的方式注入,但是在面临大规模容器集群的场景下就显得力不从心了,因此我们可以使用ConfigMap进行统一配置。

一、ConfigMap介绍

ConfigMap是Kubernetes中的一种资源对象,用于将应用配置信息存储到键值对中,Pod在使用时,将其用作环境变量、命令行参数或者存储卷中的配置文件。通过ConfigMap可以实现应用配置与容器解耦,极大方便应用配置的维护。我们通过Yaml定义一个ConfigMap并通过kubectl create创建:

$ cat cm-appvars.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: cm-appvars
data:
var1: a
var2: b
var3: c
$ sudo kubectl create -f cm-appvars.yaml
configmap/cm-appvars created
$ sudo kubectl get configmap
NAME DATA AGE
cm-appvars 3 13s
kube-root-ca.crt 1 28d
$ sudo kubectl describe configmap cm-appvars
Name: cm-appvars
Namespace: default
Labels:
Annotations: Data
====
var1:
----
a
var2:
----
b
var3:
----
c
Events:

二、在Pod中使用ConfigMap

1、通过环境变量方式使用ConfigMap

我们通过Busybox进行实验,Pod定义如下:

apiVersion: v1
kind: Pod
metadata:
name: busybox-pod
spec:
containers:
- name: busybox
image: busybox
command: ["/bin/sh", "-c", "env | grep VAR"]
env:
- name: VAR_A
valueFrom:
configMapKeyRef:
name: cm-appvars
key: var1
- name: VAR_B
valueFrom:
configMapKeyRef:
name: cm-appvars
key: var2
restartPolicy: Never

我们busybox-pod在定义时通过valueFrom.configMapKeyRef为要注入的环境变量赋值,pod启动后通过env命令打印环境变量并退出。(这里设置restartPolicy: Never避免Pod执行完命令退出后再次重启)

我们创建Pod并通过kubectl logs命令进行验证:

$ sudo kubectl create -f busy_pod.yaml
pod/busybox-pod created
$ sudo kubectl logs busybox-pod
VAR_A=a
VAR_B=b

根据输出,我们可以得知容器内部的环境变量通过使用ConfigMap的值已经被正确配置。

2、通过挂载Volume使用ConfigMap

还是以busybox为例,我们在Pod定义中,将cm-appvars中的内容以文件的形式挂载到容器内部的/vars目录下。修改后的Pod定义文件如下:

apiVersion: v1
kind: Pod
metadata:
name: busybox-pod
spec:
containers:
- name: busybox
image: busybox
command: ["/bin/sh", "-c", "top"]
volumeMounts:
- name: vars
mountPath: /vars
volumes:
- name: vars
configMap:
name: cm-appvars
items:
- key: var1 # key=var1
path: var1 # value将以var1文件名方式进行挂载
- key: var2 # key=var2
path: var2 # value将以var2文件名方式进行挂载

接着我们创建Pod并进入容器中查看是否有对应配置信息的文件:

$ sudo kubectl create -f busy_pod.yaml
pod/busybox-pod created
$ sudo kubectl exec -it busybox-pod /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # ls
bin dev etc home proc root sys tmp usr var vars / # cd vars
/vars # ls
var1 var2
/vars # cat var1
a/vars #

其实我们这里的例子很简单,在实际使用时,我们可以在ConfigMap中存储配置文件内容(如redis.conf、server.xml等),然后通过volume方式挂载到Pod中供应用加载。

三、ConfigMap的使用注意事项

在使用ConfigMap时需要注意以下几点:

1)ConfigMap必须在Pod之前创建,这样Pod才能使用它;

2)ConfigMap只能用于相同命名空间中的Pod;

3)ConfigMap无法用于静态Pod。

Docker 与 K8S学习笔记(十九)—— Pod的配置管理的

Docker 与 K8S学习笔记(十九)—— Pod的配置管理

我们在部署应用时常常会考虑将应用程序与配置文件相分离,这样可以使应用程序更好的复用,并且通过不同配置也能实现更灵活的功能。将应用制作成镜像后,我们可以在启动容器时通过环境变量或挂载文件的方式注入,但是在面临大规模容器集群的场景下就显得力不从心了,因此我们可以使用ConfigMap进行统一配置。

一、ConfigMap介绍

ConfigMap是Kubernetes中的一种资源对象,用于将应用配置信息存储到键值对中,Pod在使用时,将其用作环境变量、命令行参数或者存储卷中的配置文件。通过ConfigMap可以实现应用配置与容器解耦,极大方便应用配置的维护。我们通过Yaml定义一个ConfigMap并通过kubectl create创建:

$ cat cm-appvars.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: cm-appvars
data:
var1: a
var2: b
var3: c
$ sudo kubectl create -f cm-appvars.yaml
configmap/cm-appvars created
$ sudo kubectl get configmap
NAME DATA AGE
cm-appvars 3 13s
kube-root-ca.crt 1 28d
$ sudo kubectl describe configmap cm-appvars
Name: cm-appvars
Namespace: default
Labels:
Annotations: Data
====
var1:
----
a
var2:
----
b
var3:
----
c
Events:

二、在Pod中使用ConfigMap

1、通过环境变量方式使用ConfigMap

我们通过Busybox进行实验,Pod定义如下:

apiVersion: v1
kind: Pod
metadata:
name: busybox-pod
spec:
containers:
- name: busybox
image: busybox
command: ["/bin/sh", "-c", "env | grep VAR"]
env:
- name: VAR_A
valueFrom:
configMapKeyRef:
name: cm-appvars
key: var1
- name: VAR_B
valueFrom:
configMapKeyRef:
name: cm-appvars
key: var2
restartPolicy: Never

我们busybox-pod在定义时通过valueFrom.configMapKeyRef为要注入的环境变量赋值,pod启动后通过env命令打印环境变量并退出。(这里设置restartPolicy: Never避免Pod执行完命令退出后再次重启)

我们创建Pod并通过kubectl logs命令进行验证:

$ sudo kubectl create -f busy_pod.yaml
pod/busybox-pod created
$ sudo kubectl logs busybox-pod
VAR_A=a
VAR_B=b

根据输出,我们可以得知容器内部的环境变量通过使用ConfigMap的值已经被正确配置。

2、通过挂载Volume使用ConfigMap

还是以busybox为例,我们在Pod定义中,将cm-appvars中的内容以文件的形式挂载到容器内部的/vars目录下。修改后的Pod定义文件如下:

apiVersion: v1
kind: Pod
metadata:
name: busybox-pod
spec:
containers:
- name: busybox
image: busybox
command: ["/bin/sh", "-c", "top"]
volumeMounts:
- name: vars
mountPath: /vars
volumes:
- name: vars
configMap:
name: cm-appvars
items:
- key: var1 # key=var1
path: var1 # value将以var1文件名方式进行挂载
- key: var2 # key=var2
path: var2 # value将以var2文件名方式进行挂载

接着我们创建Pod并进入容器中查看是否有对应配置信息的文件:

$ sudo kubectl create -f busy_pod.yaml
pod/busybox-pod created
$ sudo kubectl exec -it busybox-pod /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # ls
bin dev etc home proc root sys tmp usr var vars / # cd vars
/vars # ls
var1 var2
/vars # cat var1
a/vars #

其实我们这里的例子很简单,在实际使用时,我们可以在ConfigMap中存储配置文件内容(如redis.conf、server.xml等),然后通过volume方式挂载到Pod中供应用加载。

三、ConfigMap的使用注意事项

在使用ConfigMap时需要注意以下几点:

1)ConfigMap必须在Pod之前创建,这样Pod才能使用它;

2)ConfigMap只能用于相同命名空间中的Pod;

3)ConfigMap无法用于静态Pod。

Docker 与 K8S学习笔记(十九)—— Pod的配置管理的

赞 (0)

猜您想看

评论区(暂无评论)

这里空空如也,快来评论吧~

我要评论