2.Pod的配置管理
2.1 ConfigMap的产生背景
-
外置化配置映射到容器内
应用部署的一个最佳实践是将应用所需的配置信息与程序进行分离,这样可以使应用程序被更好地复用,通过不同的配置也能实现更灵活的功能。将应用打包为容器镜像后,
可以通过环境变量或者外挂文件的方式在创建容器时进行配置注入。
-
但在大规模容器集群的环境中,对多个容器进行不同的配置将变得非常复杂
- 从Kubernetes 1.2开始提供了一种统一的应用配置管理方案—ConfigMap。本节对ConfigMap的概念和用法进行详细描述。
2.2 ConfigMap概述
ConfigMap供容器使用的典型用法如下
1. 生成为容器内的环境变量。
2. 设置容器启动命令的启动参数(需设置为环境变量)。
3. 以Volume的形式挂载为容器内部的文件或目录。
ConfigMap以一个或多个key:value的形式保存在Kubernetes系统中供应用使用,既可以用于表示一个变量的值(例如apploglevel=info),也可以用于表示一个完整配置文件的内容(例如server.xml=<?xml...>...)
可以通过YAML配置文件或者直接使用kubectl create configmap命令行的方式来创建ConfigMap。
2.3 创建ConfigMap资源对象
1.通过YAML配置文件方式创建
例子1
下面的例子cm-appvars.yaml描述了将几个应用所需的变量定义为ConfigMap的用法:
执行kubectl create命令创建该ConfigMap:
查看创建好的ConfigMap:
例子2
下面的例子cm-appconfigfiles.yaml描述了将两个配置文件server.xml和logging.properties定义为ConfigMap的用法,设置key为配置文件的别名,value则是配置文件的全部文本内容:
执行kubectl create命令创建该ConfigMap:
查看创建好的ConfigMap:
查看已创建的ConfigMap的详细内容,可以看到两个配置文件的全文:
2.通过kubectl命令行方式创建
如果 <font color=green>不使用YAML文件</font>,<font color=apple green>也可以直接通过kubectl create configmap也可以创建ConfigMap</font>,可以使用参数--from-file或-from-literal指定内容,并且可以在一行命令中指定多个参数。
(1)基于文件创建
通过--from-file参数从<font color=red>文件</font>中进行创建,可以指定key的名称,也可以在一个命令行中创建包含多个key的ConfigMap,语法为:
# kubeectl create configmap NAME --from-file=[key=]source --from-file=[key=]source
[key=]source 可以指定,默认为文件名
例子
例子1:基于1个文件
kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties
将产生以下 ConfigMap:
kubectl describe configmaps game-config-2
输出类似以下内容:
Name: game-config-2
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties: #key是文件名
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
例子2.基于多个文件
# kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties
#kubectl describe configmaps game-config-2
Name: game-config-2
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties:#key是文件名
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties: #key是文件名
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
例子3:指定key
# kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties
# kubectl get configmaps game-config-3 -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:54:22Z
name: game-config-3
namespace: default
resourceVersion: "530"
selfLink: /api/v1/namespaces/default/configmaps/game-config-3
uid: 05f8da22-d671-11e5-8cd0-68f728db1985
data:
game-special-key: |
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
(2)基于目录创建
通过--from-file参数从<font color=red>目录</font>中进行创建,该目录下的每个配置文件名都被设置为key,文件的内容被设置为value,语法为:
# kubectl create configmap NAME --from-file=config-files-dir
例子
# 创建本地目录
mkdir -p configure-pod-container/configmap/
# 将实例文件下载到 `configure-pod-container/configmap/` 目录
wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties
# 创建 configmap
kubectl create configmap game-config --from-file=configure-pod-container/configmap/
以上命令将 configure-pod-container/configmap
目录下的所有文件,也就是 game.properties
和 ui.properties
打包到 game-config ConfigMap 中。你可以使用下面的命令显示 ConfigMap 的详细信息:
#kubectl describe configmaps game-config
Name: game-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
game.properties:#key是文件名
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:#key是文件名
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
configure-pod-container/configmap/
目录中的 game.properties
和 ui.properties
文件出现在 ConfigMap 的 data
部分。
# kubectl get configmaps game-config -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T18:52:05Z
name: game-config
namespace: default
resourceVersion: "516"
selfLink: /api/v1/namespaces/default/configmaps/game-config
uid: b4952dc3-d670-11e5-8cd0-68f728db1985
data:
game.properties: |
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties: |
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
(3)基于字面值创建
使用--from-literal时会从<font color=red>字面值</font>中进行创建,直接将指定的key#=value#创建为ConfigMap的内容,语法为:
# kubectl create configmap NAME --from-literal=key1=value1 --from-literal=key2=value2
例子
# kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
# kubectl get configmaps special-config -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name: special-config
namespace: default
resourceVersion: "651"
selfLink: /api/v1/namespaces/default/configmaps/special-config
uid: dadce046-d673-11e5-8cd0-68f728db1985
data:
special.how: very
special.type: charm
2.4 在Pod中使用ConfigMap
在Pod中的使用方式:
(1)通过环境变量获取ConfigMap中的内容。
(2)通过Volume挂载的方式将ConfigMap中的内容挂载为容器内部的文件或目录。
1.通过环境变量(env)方式使用ConfigMap
(1)使用单个 ConfigMap 中的数据定义容器环境变量
kubectl create configmap special-config --from-literal=special.how=very
将 ConfigMap 中定义的 special.how
值分配给 Pod 规范中的 SPECIAL_LEVEL_KEY
环境变量。
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
#定义环境变量名
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
# 环境变量的值取自special-config
name: special-config
# key为special.how
key: special.how
restartPolicy: Never #重启策略
创建Pod
kubectl create -f pod-single-configmap-env-variable.yaml
使用kubectl create -f命令创建该Pod,由于是测试Pod,所以该Pod在执行完启动命令后将会退出,并且不会被系统自动重启(restartPolicy=Never)。
查看该Pod的日志,可以看到启动命令“env | grep special.how”的执行结果如下:
# kubectl logs pod-single-configmap-env-variable
special.how = very
(2)使用多个ConfigMap的数据定义容器的环境变量
首先创建ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
special.how: very
---
apiVersion: v1
kind: ConfigMap
metadata:
name: env-config
namespace: default
data:
log_level: INFO
创建ConfigMap
kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml
在 Pod 规范中定义环境变量
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
env:
- name: SPECIAL_LEVEL_KEY
valueFrom:
configMapKeyRef:
name: special-config
key: special.how
- name: LOG_LEVEL
valueFrom:
configMapKeyRef:
name: env-config
key: log_level
restartPolicy: Never
创建Pod
kubectl create -f pod-multiple-configmap-env-variable.yaml
(3)将ConfigMap中的所有键值对配置为容器的环境变量
上面都是使用了configMap中的部分key,在<font color=red>Kubernetes v1.6 和更高版本</font>中支持将所有键设置成容器环境变量。
例子:
创建一个包含多个键值对的 ConfigMap。
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config #该configMap名字
namespace: default
data:
SPECIAL_LEVEL: very
SPECIAL_TYPE: charm
创建 ConfigMap:
kubectl create -f configmap-multikeys.yaml
使用 envFrom
将所有 ConfigMap 的数据定义为容器环境变量,ConfigMap 中的键成为 Pod 中的环境变量名称。
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "env" ]
envFrom:
- configMapRef:
name: special-config
restartPolicy: Never
创建 Pod:
kubectl create -f pod-configmap-envFrom.yaml
环境变量的命名规则
需要说明的是,环境变量的名称受POSIX命名规范([a-zA-Z_][a-zA-Z0-9_]*)约束,不能以数字开头。如果包含非法字符,则系统将跳过该条环境变量的创建,并记录一个Event来提示环境变量无法生成,但并不阻止Pod的启动。
2.通过volumeMount使用ConfigMap
例子
本节中的示例引用了一个名为 special-config 的 ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: special-config
namespace: default
data:
SPECIAL_LEVEL: very
SPECIAL_TYPE: charm
创建 ConfigMap:
kubectl create -f configmap-multikeys.yaml
例1.使用存储在 ConfigMap 中的数据填充数据卷
在 Pod 规约的 volumes
部分下添加 ConfigMap 名称。 这会将 ConfigMap 数据添加到指定为 volumeMounts.mountPath
的目录(在本例中为 /etc/config
)。 command
部分引用存储在 ConfigMap 中的 special.level
。
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh", "-c", "ls /etc/config/" ]
volumeMounts: #卷挂载
- name: config-volume #引用volume名字
mountPath: /etc/config #挂载到容器内的目录
volumes:
- name: config-volume # 定义volume名字
configMap:
# 引用的configMap名字,不指定items,则使用volumeMount方式在容器内的目录下为每个item都生成一个文件名为key的文件
name: special-config
restartPolicy: Never
创建 Pod:
kubectl create -f pod-configmap-volume.yaml
Pod 运行时,命令 ls /etc/config/
产生下面的输出:
SPECIAL_LEVEL #基于文件创建configMap, 如果不指定key,key默认是文件名
SPECIAL_TYPE
注意:
如果在 /etc/config/
目录中有一些文件,它们将被删除。
说明:
文本数据会使用 UTF-8 字符编码的形式展现为文件。如果使用其他字符编码, 可以使用 binaryData
。
例2.将 ConfigMap 数据添加到数据卷中的特定路径
使用 path
字段为特定的 ConfigMap 项目指定预期的文件路径。 在这里,ConfigMap中,键值 SPECIAL_LEVEL
的内容将挂载在 config-volume
数据卷中 /etc/config/keys
.properties 文件下。
apiVersion: v1
kind: Pod
metadata:
name: dapi-test-pod
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "/bin/sh","-c","cat /etc/config/keys" ] #子命令,可直接通过kubectl + command操作k8s资源
volumeMounts:
- name: config-volume
mountPath: /etc/config
volumes:
- name: config-volume
configMap:
name: special-config
items:
- key: SPECIAL_LEVEL #key=SPECIAL_LEVEL
path: keys.properties # value将以keys.properties 文件名进行挂载
restartPolicy: Never
创建Pod:
kubectl create -f pod-configmap-volume-specific-key.yaml
当 pod 运行时,命令 cat /etc/config/keys
产生以下输出
very
注意:
/etc/config/
目录中所有先前的文件都将被删除。
3.挂载的 ConfigMap 将自动更新
更新已经在数据卷中使用的 ConfigMap 时,已映射的键最终也会被更新。 kubelet
在每次定期同步时都会检查已挂载的 ConfigMap 是否是最新的。 但是,它使用其本地的基于 TTL 的缓存来获取 ConfigMap 的当前值。 因此,从更新 ConfigMap 到将新键映射到 Pod 的总延迟可能与 kubelet 同步周期 + ConfigMap 在 kubelet 中缓存的 TTL 一样长。
注意:
使用 ConfigMap 作为subPath的数据卷将不会收到ConfigMap更新。
4.使用ConfigMap的限制条件
-
在 Pod 规范中引用之前,必须先创建一个 ConfigMap(除非将 ConfigMap 标记为"可选")。
如果引用的 ConfigMap 不存在,则 Pod 将不会启动。
同样,引用 ConfigMap 中不存在的键也会阻止 Pod 启动。
-
如果通过环境变量使用ConfigMap,那么无效的键将被忽略,可以启动pod。
- 在事件日志中(
InvalidVariableNames
)。 日志消息列出了每个跳过的键。例如:
- 在事件日志中(
# kubectl get events
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.
ConfigMap受Namespace限制,只有处于相同Namespace中的Pod才可以引用它。
ConfigMap中的配额管理还未能实现。
-
静态Pod不支持ConfigMap
- kubelet只支持可以被API Server管理的Pod使用ConfigMap。kubelet在本Node上通过 --manifest-url或--config自动创建的静态Pod将无法引用ConfigMap。
-
在通过volumeMount使用ConfigMap时,在容器内部只能挂载为“目录”,无法挂载为“文件”。
在挂载到容器内部后,在目录下将包含ConfigMap定义的每个item,如果在该目录下原来还有其他文件,则容器内的该目录将被挂载的ConfigMap覆盖
如果应用程序需要保留原来的其他文件,则需要进行额外的处理。可以将ConfigMap挂载到容器内部的临时目录,再通过启动脚本将配置文件复制或者链接到(cp或link命令)应用所用的实际配置目录下。
3.在容器内获取Pod信息(Downward API)
我们知道,每个Pod在被成功创建出来之后,都会被系统分配唯一的名字、IP地址,并且处于某个Namespace中,那么我们如何在Pod的容器内获取Pod的这些重要信息呢?答案就是使用Downward API。
Downward API可以通过以下两种方式将Pod信息注入容器内部。
(1)环境变量:用于单个变量,可以将Pod信息和Container信息注入容器内部。
(2)Volume挂载:将数组类信息生成为文件并挂载到容器内部。
这两种呈现 Pod 和 Container 字段的方式统称为 Downward API。
3.1 通过环境变量方式获取Pod信息
<font color=green>因为可以通过将Pod的信息(Pod中的字段值)或Container的信息(容器中的字段值)注入到Pod的环境变量中</font>,所以这个环境变量的值可能取自两个地方:
-
pod中的字段
- pod中的字段获取的范围大于容器中的字段。
容器中的字段
以上两种方式只是获取的范围不同。
文档地址:
https://kubernetes.io/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/
3.1.1 获取用Pod字段作为环境变量的值
apiVersion: v1
kind: Pod
metadata:
name: dapi-envars-fieldref
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox
command: [ "sh", "-c"]
args:
- while true; do
echo -en '\n';
printenv MY_NODE_NAME MY_POD_NAME MY_POD_NAMESPACE;
printenv MY_POD_IP MY_POD_SERVICE_ACCOUNT;
sleep 10;
done;
env: #环境数组
- name: MY_NODE_NAME #第一个环境变量
valueFrom:
fieldRef:
fieldPath: spec.nodeName #从 Pod 的 spec.nodeName 字段获取变量值,本集群是通过minikube工具创建,nodeName=minikube
- name: MY_POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: MY_POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: MY_POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: MY_POD_SERVICE_ACCOUNT
valueFrom:
fieldRef:
fieldPath: spec.serviceAccountName
restartPolicy: Never
注意到上面valueFrom这种特殊的语法是Downward API的写法。目前Downward API提供了以下变量。
metadata.name:Pod的名称,当Pod通过RC生成时,其名称是RC随机产生的唯一名称。
status.podIP:Pod的IP地址,之所以叫作status.podIP而非metadata.IP,是因为Pod的IP属于状态数据,而非元数据。
metadata.namespace:Pod所在的Namespace。
创建pod
kubectl apply -f dapi-envars-pod.yaml
查看容器日志:
# kubectl logs dapi-envars-fieldref
minikube
dapi-envars-fieldref
default
172.17.0.4
default
注意:
当容器启动时,它将五个环境变量的值写入 stdout。每十秒重复执行一次。
接下来,通过打开一个 Shell 进入 Pod 中运行的容器:
# kubectl exec -it dapi-envars-fieldref -- sh
在 Shell 中,查看环境变量:
/# printenv
MY_POD_SERVICE_ACCOUNT=default
...
MY_POD_NAMESPACE=default
MY_POD_IP=172.17.0.4
...
MY_NODE_NAME=minikube
...
MY_POD_NAME=dapi-envars-fieldref
3.1.2 获取用Container字段作为环境变量的值
将容器资源信息注入为环境变量
apiVersion: v1
kind: Pod
metadata:
name: dapi-envars-resourcefieldref
spec:
containers:
- name: test-container
image: k8s.gcr.io/busybox:1.24
command: [ "sh", "-c"]
args:
- while true; do
echo -en '\n';
printenv MY_CPU_REQUEST MY_CPU_LIMIT;
printenv MY_MEM_REQUEST MY_MEM_LIMIT;
sleep 10;
done;
resources:
requests:
memory: "32Mi"
cpu: "125m"
limits:
memory: "64Mi"
cpu: "250m"
env:
- name: MY_CPU_REQUEST
valueFrom:
resourceFieldRef:
containerName: test-container
resource: requests.cpu
- name: MY_CPU_LIMIT
valueFrom:
resourceFieldRef:
containerName: test-container
resource: limits.cpu
- name: MY_MEM_REQUEST
valueFrom:
resourceFieldRef:
containerName: test-container
resource: requests.memory
- name: MY_MEM_LIMIT
valueFrom:
resourceFieldRef:
containerName: test-container
resource: limits.memory
restartPolicy: Never
注意valueFrom这种特殊的Downward API语法,目前resourceFieldRef可以将容器的资源请求和资源限制等配置设置为容器内部的环境变量。
requests.cpu:容器的CPU请求值。
limits.cpu:容器的CPU限制值。
requests.memory:容器的内存请求值。
limits.memory:容器的内存限制值。
创建Pod:
kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml
查看容器日志
# kubectl logs dapi-envars-resourcefieldref
1
1
33554432
67108864
3.2 通过volumeCount方式获取Pod信息
当然Pod的环境变量的取值可以通过Pod字段或Container字段指定,下面例子演示一个通过Pod字段演示。
例子:
Pod的配置信息
apiVersion: v1
kind: Pod
metadata:
name: kubernetes-downwardapi-volume-example
labels:
zone: us-est-coast
cluster: test-cluster1
rack: rack-22
annotations:
build: two
builder: john-doe
spec:
containers:
- name: client-container
image: k8s.gcr.io/busybox
command: ["sh", "-c"]
args:
- while true; do
if [[ -e /etc/podinfo/labels ]]; then
echo -en '\n\n'; cat /etc/podinfo/labels; fi;
if [[ -e /etc/podinfo/annotations ]]; then
echo -en '\n\n'; cat /etc/podinfo/annotations; fi;
sleep 5;
done;
volumeMounts:
- name: podinfo
mountPath: /etc/podinfo
volumes:
- name: podinfo
downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- path: "annotations"
fieldRef:
fieldPath: metadata.annotations
注意:
本示例中的字段是Pod字段,不是Pod中容器的字段。
创建 Pod:
kubectl apply -f dapi-volume.yaml
查看容器的日志:
# kubectl logs kubernetes-downwardapi-volume-example
输出显示 labels 和 annotations 文件的内容:
cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"
build="two"
builder="john-doe"
进入 Pod 中运行的容器,打开一个 Shell:
# kubectl exec -it kubernetes-downwardapi-volume-example -- sh
在该 Shell中,查看 labels
文件:
/# cat /etc/podinfo/labels
输出显示 Pod 的所有标签都已写入 labels
文件。
cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"
查看annotations文件同理。
在输出中可以看到,labels
和 annotations
文件都在一个临时子目录中。 在这个例子,..2982_06_02_21_47_53.299460680
。 在 /etc/podinfo
目录中,..data
是一个指向临时子目录 的符号链接。/etc/podinfo
目录中,labels
和 annotations
也是符号链接。
drwxr-xr-x ... Feb 6 21:47 ..2982_06_02_21_47_53.299460680
lrwxrwxrwx ... Feb 6 21:47 ..data -> ..2982_06_02_21_47_53.299460680
lrwxrwxrwx ... Feb 6 21:47 annotations -> ..data/annotations
lrwxrwxrwx ... Feb 6 21:47 labels -> ..data/labels
/etc/podinfo/..2982_06_02_21_47_53.299460680:
total 8
-rw-r--r-- ... Feb 6 21:47 annotations
-rw-r--r-- ... Feb 6 21:47 labels
3.3 Downward API的价值
-
通过环境变量或文件方式获取Pod自身的名称、IP地址等信息,然后将这些信息写入主程序的配置文件中然后发布息发布到某个类似服务注册中心的地方,以实现集群节点的自动发现功能
在某些集群中,集群中的每个节点都需要将自身的标识(ID)及进程绑定的IP地址等信息事先写入配置文件中,进程在启动时会读取这些信息,然后将这些信息发布到某个类似服务注册中心的地方,以实现集群节点的自动发现功能。
此时Downward API就可以派上用场了,具体做法是先编写一个预启动脚本或Init Container,通过环境变量或文件方式获取Pod自身的名称、IP地址等信息,然后将这些信息写入主程序的配置文件中,最后启动主程序。