Kubernetes Downward API

目录

• 说明
• 环境变量方式
  • 将pod信息注入为环境变量
  • 将容器资源信息注入为环境变量
• volume挂载方式
• 作用

说明

我们知道，每个Pod在成功创建出来之后，都会被系统分配唯一的名字、IP地址，并且处于某一个namespace中，那么我们如何在pod的容器内获取pod的这些重要信息呢？ 答案就是使用Downward API。
Downward API可以通过以下两种方式将pod信息注入容器内部：

• 环境变量：用于单个变量，可以将pod信息和container信息注入容器内部。
• volume挂载：将数组类信息生成为文件，挂载到容器内部。

环境变量方式

将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: NODE_NAME
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName
    - name: MY_POD_SERVICE_ACCOUNT
      valueFrom:
        fieldRef:
          fieldPath: spec.serviceAccountName
    - 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

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

• spec.nodeName：Pod所在节点的名称
• spec.serviceAccountName：pod运行时使用的serivceAccount的名称
• metadata.name: Pod的名称，当pod通过rc生成时，其名称是rc随机产生的唯一名称
• status.podIP: Pod的ip地址，之所以叫status.podIP而非metadata.IP，是因为pod的ip属于状态数据，而非元数据
• metadata.namespace: pod所在的namespace

将容器资源信息注入为环境变量

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

dapi-test-pod-container-vars.yaml内容如下：

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

目前resourceFieldRef可以将容器的资源请求和资源限制等配置设置为容器内部的环境变量。

• requests.cpu
• limits.cpu
• requests.memory
• limits.memory

volume挂载方式

下面的示例通过Downward API将pod的label、annotation列表通过volume挂载为容器内的一个文件，容器应用使用echo命令将文件内容打印到标准输出：

dapi-test-pod-volume.yaml内容如下：

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: Breeze
spec:
  containers:
  - name: test-container
    image: busybox
    imagePullPolicy: Never
    command: ["sh","-c"]
    args:
    - while true; do
        if [[ -e /etc/labels ]];then
          echo -en '

';cat /etc/labels;
        fi
        if [[ -e /etc/annotations ]];then
          echo -en '

';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

上面的示例中，通过items的设置，将会以path的名称生成文件。这里将在容器内生成/etc/labels和/etc/annotations两个文件，/etc/labels中将包含metadata.labels的全部label列表，/etc/annotations中将包含metadata.annotations的全部label列表

作用

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

参考：《kubernetes权威指南》