在容器内获取Pod信息
我们知道,每个Pod在被成功创建出来之后,都会被系统分配唯一 的名字、IP地址,并且处于某个Namespace中,那么我们如何在Pod的容 器内获取Pod的这些重要信息呢?答案就是使用Downward API。 Downward API可以通过以下两种方式将Pod信息注入容器内部。
(1)环境变量:用于单个变量,可以将Pod信息和Container信息注 入容器内部。
(2)Volume挂载:将数组类信息生成为文件并挂载到容器内部。 下面通过几个例子对Downward API的用法进行说明。
环境变量方式:将Pod信息注入为环境变量
下面的例子通过Downward API将Pod的IP、名称和所在Namespace 注入容器的环境变量中,容器应用使用env命令将全部环境变量打印到标准输出中:
apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: busybox command: [ "/bin/sh", "-c", "env" ] env: - 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 restartPolicy: Never
查看日志
[root@lab-26 test]# kubectl logs dapi-test-pod|grep MY MY_POD_NAMESPACE=default MY_POD_IP=172.152.106.5 MY_POD_NAME=dapi-test-pod
注意到上面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的IP、Name及Namespace等信息都被正 确保存到了Pod的环境变量中。
环境变量方式:将容器资源信息注入为环境变量
下面的例子通过Downward API将Container的资源请求和限制信息注入容器的环境变量中,容器应用使用printenv命令将设置的资源请求 和资源限制环境变量打印到标准输出中
apiVersion: v1 kind: Pod metadata: name: dapi-test-pod-container-vars spec: containers: - name: test-container image: busybox imagePullPolicy: Never command: [ "sh", "-c"] args: - while true; do echo -en ' '; printenv MY_CPU_REQUEST MY_CPU_LIMIT; printenv MY_MEM_REQUEST MY_MEM_LIMIT; sleep 3600; 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
查看日志
[root@lab-26 test]# kubectl logs dapi-test-pod-container-vars 1 1 33554432 67108864
注意valueFrom这种特殊的Downward API语法,目前resourceFieldRef可以将容器的资源请求和资源限制等配置设置为容器内部的环境变量
- requests.cpu:容器的CPU请求值
- limits.cpu:容器的CPU限制值
- requests.memory:容器的内存请求值
- limits.memory:容器的内存限制值
Volume挂载方式
下面的例子通过Downward API将Pod的Label、Annotation列表通过 Volume挂载为容器中的一个文件,容器应用使用echo命令将文件的内容 打印到标准输出中:
apiVersion: v1 kind: Pod metadata: name: dapi-test-pod-volume labels: zone: us-est-coast cluster: test-cluster1 rack: rack-22 annotations: build: two builder: john-doe spec: containers: - name: test-container image: busybox imagePullPolicy: Never command: ["sh", "-c"] args: - while true; do if [[ -e /tmp/labels ]]; then echo -en ' '; cat /tmp/labels; fi; if [[ -e /tmp/annotations ]]; then echo -en ' '; cat /tmp/annotations; fi; sleep 3600; done; volumeMounts: - name: podinfo mountPath: /tmp/ readOnly: false volumes: - name: podinfo downwardAPI: items: - path: "labels" fieldRef: fieldPath: metadata.labels - path: "annotations" fieldRef: fieldPath: metadata.annotations
通过items 的设置,系统会根据path的名称生成文件,根据上例的设置,系统将在 容器内生成/etc/labels和/etc/annotations两个文件,在/etc/labels文件中将 包含metadata.labels的全部Label列表,在/etc/annotations文件中将包含 metadata.annotations的全部Label列表
查看结果
[root@lab-26 ~]# kubectl logs dapi-test-pod-volume cluster="test-cluster1" rack="rack-22" zone="us-est-coast"
Downward API用处
在某些集群中,集群中的每个节点都需要将自身的标识(ID)及进程绑定的IP地址等信息事先写入配置文件中,进程在启动时会读取这些 信息,然后将这些信息发布到某个类似服务注册中心的地方,以实现集 群节点的自动发现功能。此时Downward API就可以派上用场了,具体 做法是先编写一个预启动脚本或Init Container,通过环境变量或文件方 式获取Pod自身的名称、IP地址等信息,然后将这些信息写入主程序的 配置文件中,最后启动主程序