哈喽~大家好！昨天我们讲解了ConfigMap的使用，今天我来继续深入的讨论Pod的概念及其用法。
现在我们进入正题。
Downward API
我们知道，每个Pod在被成功创建出来之后，都会被系统分配唯一的名字、IP地址，并且处于某个Namespace中，那么我们如何在Pod的容器内获取Pod的这些重要信息呢？答案就是使用Downward API。
Downward API可以通过以下两种方式将Pod信息注入容器内部。
（1）环境变量：用于单个变量，可以将Pod信息和Container信息注入容器内部。
（2）Volume挂载：将数组类信息生成为文件并挂载到容器内部。
下面通过几个例子对Downward API的用法进行说明。
将Pod信息注入为环境变量
下面的例子通过Downward API将Pod的IP、名称和所在Namespace注入容器的环境变量中，容器应用使用env命令将全部环境变量打印到标准输出中：
dapi-test-pod.yaml内容如下：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
2apiVersion: v1
3kind: Pod
4metadata:
5 name: dapi-test-pod
6spec:
7 containers:
8 - name: test-container
9 image: busybox
10 command: ["/bin/sh","-c","env"]
11 env:
12 - name: MY_POD_NAME
13 valueFrom:
14 fieldRef:
15 fieldPath: metadata.name
16 - name: MY_POD_NAMESPACE
17 valueFrom:
18 fieldRef:
19 fieldPath: metadata.namespace
20 - name: MY_POD_IP
21 valueFrom:
22 fieldRef:
23 fieldPath: status.podIP
24
25
注意到上面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。
查看dapi-test-pod的日志：
从日志中我们可以看到Pod的IP、Name及Namespace等信息都被正确保存到了Pod的环境变量中。
将容器资源信息注入为环境变量
下面的例子通过Downward API将Container的资源请求和限制信息注入容器的环境变量中，容器应用使用printenv命令将设置的资源请求和资源限制环境变量打印到标准输出中：
dapi-test-pod-container-vars.yaml文件内容如下：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
2kind: Pod
3metadata:
4 name: dapi-test-pod-container-vars
5spec:
6 containers:
7 - name: test-container
8 image: busybox
9 imagePullPolicy: Never
10 command: [ "sh", "-c"]
11 args:
12 - while true; do
13 echo -en '\n';
14 printenv MY_CPU_REQUEST MY_CPU_LIMIT;
15 printenv MY_MEM_REQUEST MY_MEM_LIMT;
16 sleep 3600;
17 done;
18 resources:
19apiVersion: v1
20kind: Pod
21metadata:
22 name: dapi-test-pod-container-vars
23spec:
24 containers:
25 - name: test-container
26 image: busybox
27 imagePullPolicy: Never
28 command: [ "sh", "-c"]
29 args:
30 - while true; do
31 echo -en '\n';
32 printenv MY_CPU_REQUEST MY_CPU_LIMIT;
33 printenv MY_MEM_REQUEST MY_MEM_LIMIT;
34 sleep 3600;
35 done;
36 resources:
37 requests:
38 memory: "32Mi"
39 cpu: "125m"
40 limits:
41 memory: "64Mi"
42 cpu: "250m"
43 env:
44 - name: MY_CPU_REQUEST
45 valueFrom:
46 resourceFieldRef:
47 containerName: test-container
48 resource: requests.cpu
49 - name: MY_CPU_LIMIT
50 valueFrom:
51 resourceFieldRef:
52 containerName: test-container
53 resource: limits.cpu
54 - name: MY_MEM_REQUEST
55 valueFrom:
56 resourceFieldRef:
57 containerName: test-container
58 resource: requests.memory
59 - name: MY_MEM_LIMIT
60 valueFrom:
61 resourceFieldRef:
62 containerName: test-container
63 resource: limits.memory
64 restartPolicy: Never
65
66
注意valueFrom这种特殊的Downward API语法，目前resourceFieldRef可以将容器的资源请求和资源限制等配置设置为容器内部的环境变量。
◎ requests.cpu：容器的CPU请求值。
◎ limits.cpu：容器的CPU限制值。
◎ requests.memory：容器的内存请求值。
◎ limits.memory：容器的内存限制值。
查看dapi-test-pod-container-vars的日志：
从日志中我们可以看到Container的requests.cpu、limits.cpu、requests.memory、limits.memory等信息都被正确保存到了Pod的环境变量中。
Volume挂载方式
下面的例子通过Downward API将Pod的Label、Annotation列表通过Volume挂载为容器中的一个文件，容器应用使用echo命令将文件的内容打印到标准输出中：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
2kind: Pod
3metadata:
4 name: dapi-test-pod-volume
5 labels:
6 zone: us-est-coast
7 cluster: test-cluster1
8 rack: rack-22
9 annotations:
10 build: two
11 builder: john-doe
12spec:
13 containers:
14 - name: test-container
15 image: busybox
16 imagePullPolicy: Never
17 command: ["sh","-c"]
18 args:
19 - while true; do
20 if [[ -e /etc/labels ]]; then
21 echo -en '\n\n'; cat /etc/labels; fi;
22 if [[ -e /etc/annotations ]]; then
23 echo -en '\n\n'; cat /etc/annotations; fi;
24 sleep 3600;
25 done;
26 volumeMounts:
27 - name: podinfo
28 mountPath: /etc
29 readOnly: false
30 volumes:
31 - name: podinfo
32 downwardAPI:
33 items:
34 - path: "labels"
35 fieldRef:
36 fieldPath: metadata.labels
37 - path: "anntotations"
38 fieldRef:
39 fieldPath: metadata.annotations
40
41
╭(╯^╰)╮ 此实例博主没有跑通，这里就理解这来吧~ 明天我深入研究一下，是什么问题，报错截图如下：
这里要注意“volumes”字段中downwardAPI的特殊语法，通过items的设置，系统会根据path的名称生成文件。根据上例的设置，系统将在容器内生成/etc/labels和/etc/annotations两个文件。在/etc/labels文件中将包含metadata.labels的全部Label列表，在/etc/annotations文件中将包含metadata.annotations的全部Label列表。
在某些集群中，集群中的每个节点都需要将自身的标识（ID）及进程绑定的IP地址等信息事先写入配置文件中，进程在启动时会读取这些信息，然后将这些信息发布到某个类似服务注册中心的地方，以实现集群节点的自动发现功能。此时Downward API就可以派上用场了，具体做法是先编写一个预启动脚本或Init Container，通过环境变量或文件方式获取Pod自身的名称、IP地址等信息，然后将这些信息写入主程序的配置文件中，最后启动主程序。
