1. 在容器内获取Pod信息（Downward API）

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

Downward API 可以通过以下两种方式将Pod信息注入容器内部：
（1）环境变量：用于单个变量，可以将Pod信息和Container信息注入容器内部；
（2）Volume挂载：将数组类信息生成为文件，挂载到容器内部。
下面通过几个例子对Downward API的用法进行说明：

1.1 环境变量方式——将Pod信息注入为环境变量

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: metadata.name
  restartPolicy: Never

运行kubectl create命令创建Pod：

$ kubectl create -f dapi-test-pod.yaml

查看dapi-test-pod的日志：

$ kubectl logs dapi-test-pod
MY_POD_NAMESPACE=default
MY_POD_IP=dapi-test-pod
MY_POD_NAME=dapi-test-pod

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

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

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod-container-vars
spec:
  containers:
  - name: test-container
    image: busybox
    imagePullPolicy: Never
    command: ["/bin/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: requests.memory
  restartPolicy: Never

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

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

1.3 以Volume挂载方式

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
          readOnly: false
  volumes:
    - name: podinfo
      downwardAPI:
        items:
          - path: "labels"
            fieldRef:
              fieldPath: metadata.labels
          - path: "annotations"
            fieldRef:
              fieldPath: metadata.annotations

在配置文件中，你可以看到Pod有一个downwardAPI类型的Volume，并且挂载到容器中的/etc。

查看downwardAPI下面的items数组。每个数组元素都是一个DownwardAPIVolumeFile。第一个元素指示Pod的metadata.labels字段的值保存在名为labels的文件中。第二个元素指示Pod的annotations字段的值保存在名为annotations的文件中。

2. Capabilities of the Downward API

下面这些信息可以通过环境变量和DownwardAPIVolumeFiles提供给容器：

能通过fieldRef获得的： * metadata.name - Pod名称 * metadata.namespace - Pod名字空间 * metadata.uid - Pod的UID, 版本要求 v1.8.0-alpha.2 * metadata.labels[''] - 单个 pod 标签值 (例如, metadata.labels['mylabel']); 版本要求 Kubernetes 1.9+ * metadata.annotations[''] - 单个 pod 的标注值 (例如, metadata.annotations['myannotation']); 版本要求 Kubernetes 1.9+

能通过resourceFieldRef获得的： * 容器的CPU约束值 * 容器的CPU请求值 * 容器的内存约束值 * 容器的内存请求值 * 容器的临时存储约束值, 版本要求 v1.8.0-beta.0 * 容器的临时存储请求值, 版本要求 v1.8.0-beta.0

此外，以下信息可通过DownwardAPIVolumeFiles从fieldRef获得：

metadata.labels - all of the pod’s labels, formatted as label-key="escaped-label-value" with one label per line
metadata.annotations - all of the pod’s annotations, formatted as annotation-key="escaped-annotation-value" with one annotation per line
metadata.labels - 所有Pod的标签，以label-key="escaped-label-value"格式显示，每行显示一个label
metadata.annotations - Pod的注释，以annotation-key="escaped-annotation-value"格式显示，每行显示一个标签
以下信息可通过环境变量从fieldRef获得：

status.podIP - 节点IP
spec.serviceAccountName - Pod服务帐号名称, 版本要求 v1.4.0-alpha.3
spec.nodeName - 节点名称, 版本要求 v1.4.0-alpha.3
status.hostIP - 节点IP, 版本要求 v1.7.0-alpha.1

3. Downward API的动机

对于容器来说，有时候拥有自己的信息是很有用的，可避免与Kubernetes过度耦合。Downward API使得容器使用自己或者集群的信息，而不必通过Kubernetes客户端或API服务器。

一个例子是有一个现有的应用假定要用一个非常熟悉的环境变量来保存一个唯一标识。一种可能是给应用增加处理层，但这样是冗余和易出错的，而且它违反了低耦合的目标。更好的选择是使用Pod名称作为标识，把Pod名称注入这个环境变量中。

4. 参考文件

通过文件将Pod信息呈现给容器
Kubernetes权威指南

Pod Downward API