Downward API —— 在容器内部获取 Pod 信息

我们知道，每个 Pod 在被超过创建出来之后，都会被系统分配唯一的名字、IP地址，并且处于某个 Namespace 中，那么我们如何在 Pod 的容器内获取 Pod 的这些重要信息呢？
答案就是使用 Downward API。

Downward API 可以通过以下两种方式将 Pod 信息注入容器内部。

1. 环境变量：用于单个变量，可以将 Pod 信息和 Container 信息注入容器内部。
2. Volume 挂载：将数组类信息生成为文件并挂载到容器内部。

3.6.1 环境变量方式：将 Pod 信息注入为环境变量

下面的例子通过 Downward API 将 Pod 的IP、名称和所在 Namespace 注入容器的环境变量中，容器应用使用 env 命令将全部环境变量大隐刀标准输出中：

dapi-test-pod.yaml

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

注意到上面 valurFrom 这种特殊的语法是 Downward API 的写法。
目前 Downward API 提供了以下变量。

• metadata.name: Pod 的名称，当 Pod 通过 RC 生成时，其名称是 RC 随机产生的唯一名称。
• status.podIP: Pod 的 IP 地址，之所以叫做status.podIP 而非 metadata.IP，是因为 Pod 的 IP 属于状态数据，而非元数据。
• metadata.namespace: Pod 所在的 Namespace。

运行 kubectl create 命令创建 Pod：

# kubectl create -f dapi-test-pod.yaml
pod "dapi-test-pod" created

查看 dapi-test-pod 的日志：

.....
MY_POD_NAMESPACE=default
MY_POD_IP=172.17.1.2
MY_POD_NAME=dapi-test-pod
.....

从日志中我们可以看到 Pod 的 IP、Name 及 Namespace 等信息都被正确保存到了 Pod 的环境变量中。

3.6.2 环境变量方式：将容器资源信息注入为环境变量

下面的例子通过Downward API将 Container 的资源请求和限制信息注入容器的环境变量中，容器应用使用printenv命令将设置的资源环境变量打印到标准输出中：

dapi-test-pod-container-vars.yaml

apiVersion: v1
kind: Pod
  name: dapi-test-pod-container-vars
spec:
  containers:
    - name: test-container
      image: busybox
      imagePullPolicy: Never
      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 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

注意 valueFrom 这种特殊的 Downward API 语法，目前 resourceFieldRef 可以将容器的资源请求和资源限制等设置为容器内部的环境变量。

• requests.cpu: 容器的 CPU 请求值。
• limits.cpu: 容器的 CPU 限制值。
• requests.memory: 容器的内存请求值。
• limits.memory: 容器的内存限制值。

运行 kubectl create 命令来创建 Pod：

# kubectl create -f dapi-test-pod-container-vars.yaml
pod "dapi-test-pod-container-vars" created

# kubectl get pods
NAME                      READY   STATUS     RESTARTS   AGE
dapi-test-pod-container-vars  1/1    Running    0         36s

查看 dapi-test-pod-container-vars 的日志：

# kubectl logs dapi-test-pod-container-vars
1
1
33554432
67100864

从日志中我们可以看到 Container 的 requests.cpu、limits.cpu、requests.memory、limits.memory 等信息都被正确保存到了 Pod 的环境变量中。

3.6.3 Volume 挂载方式

下面的例子通过 Downward API 将 Pod 的 Label、Annotation 列表通过 Volume 挂载为容器中的一个文件，容器应用使用 echo 命令将文件的内容打印到标准输出中：

dapi-test-pod-volume.yaml

apiVersion: v1
kind: Pod
  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 /etc/labels ]]; then
          echo -en '\n\n'; cat /etc/labels; fi;
         if [[ -e /etc/annotations ]]; then
          echo -en '\n\n'; cat /etc/annotations; fi;
         sleep 3600;
        done;
      volumeMounts:
        - name: podinfo
          mountPath: /etc
          readOnly: false
  volumes:
    - name: podinfo
      downwardAPI:
        items:
          - path: "labels"
            fieldRef:
             fieldPath: metadata.labels
          - path: "annotations"
            fieldRef:
             fieldPath: metadata.annotations

这里要注意 “volumes” 字段中 downwardAPI 的特殊语法，通过items的设置，系统会根据 path 的名称生成文件。
根据上例的设置，系统将在容器内生成/etc/labels 和 /etc/annotations 两个文件。
在/etc/labels 文件中将包含metadata.labels的全部Label列表，在/etc/annotations文件中将包含metadata.annotations 的全部 Label 列表。

运行 kubectl create 命令创建 Pod：

# kubectl create -f dapi-test-pod-volume.yaml
pod "dapi-test-pod-volume" created

# kubectl get pods
NAME                      READY   STATUS     RESTARTS   AGE
dapi-test-pod-volume         1/1    Running    0         39s

查看 dapi-test-pod-valume 的日志：

# kubectl logs dapi-test-pod-volume
cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"

build="two"
builder="john-doe"

从日志中我们看到 Pod 的 Label 和 Annotation 信息都被保存到了容器内的 /etc/labels 和 /etc/annotations 文件中。

那么，Downward API 有什么价值呢？

在某些集群中，集群中的每个节点都需要将自身的标识（ID）及进程绑定的 IP 地址等信息事先写入配置文件中，进程在启动时会读取这些信息，然后将这些信息发布到某个类似服务注册中心的地方，以实现集群节点的自动发现功能。
此时 Downward API 就可以派上用场了，具体做法是先编写一个与启动脚本或 Init Container，通过环境变量或文件方式获取 Pod 自身的名称、IP 地址等信息，然后将这些信息写入主程序的配置文件中，最后启动主程序。