Expose Pod Information to Containers Through Files

This page shows how a Pod can use a DownwardAPIVolumeFile to expose information about itself to Containers running in the Pod. A DownwardAPIVolumeFile can expose Pod fields and Container fields.

Before you begin

You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:

To check the version, enter kubectl version.

The Downward API

There are two ways to expose Pod and Container fields to a running Container:

Together, these two ways of exposing Pod and Container fields are called the Downward API.

Store Pod fields

In this exercise, you create a Pod that has one Container. Here is the configuration file for the Pod:

pods/inject/dapi-volume.yaml Expose Pod Information to Containers Through Files - 图1

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: kubernetes-downwardapi-volume-example
  5.   labels:
  6.     zone: us-est-coast
  7.     cluster: test-cluster1
  8.     rack: rack-22
  9.   annotations:
  10.     build: two
  11.     builder: john-doe
  12. spec:
  13.   containers:
  14.     - name: client-container
  15.       image: k8s.gcr.io/busybox
  16.       command: ["sh", "-c"]
  17.       args:
  18.       - while true; do
  19.           if [[ -e /etc/podinfo/labels ]]; then
  20.             echo -en '\n\n'; cat /etc/podinfo/labels; fi;
  21.           if [[ -e /etc/podinfo/annotations ]]; then
  22.             echo -en '\n\n'; cat /etc/podinfo/annotations; fi;
  23.           sleep 5;
  24.         done;
  25.       volumeMounts:
  26.         - name: podinfo
  27.           mountPath: /etc/podinfo
  28.   volumes:
  29.     - name: podinfo
  30.       downwardAPI:
  31.         items:
  32.           - path: "labels"
  33.             fieldRef:
  34.               fieldPath: metadata.labels
  35.           - path: "annotations"
  36.             fieldRef:
  37.               fieldPath: metadata.annotations

In the configuration file, you can see that the Pod has a downwardAPI Volume, and the Container mounts the Volume at /etc/podinfo.

Look at the items array under downwardAPI. Each element of the array is a DownwardAPIVolumeFile. The first element specifies that the value of the Pod’s metadata.labels field should be stored in a file named labels. The second element specifies that the value of the Pod’s annotations field should be stored in a file named annotations.

Note: The fields in this example are Pod fields. They are not fields of the Container in the Pod.

Create the Pod:

  1. kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume.yaml

Verify that the Container in the Pod is running:

  1. kubectl get pods

View the Container’s logs:

  1. kubectl logs kubernetes-downwardapi-volume-example

The output shows the contents of the labels file and the annotations file:

  1. cluster="test-cluster1"
  2. rack="rack-22"
  3. zone="us-est-coast"
  5. build="two"
  6. builder="john-doe"

Get a shell into the Container that is running in your Pod:

  1. kubectl exec -it kubernetes-downwardapi-volume-example -- sh

In your shell, view the labels file:

  1. /# cat /etc/podinfo/labels

The output shows that all of the Pod’s labels have been written to the labels file:

  1. cluster="test-cluster1"
  2. rack="rack-22"
  3. zone="us-est-coast"

Similarly, view the annotations file:

  1. /# cat /etc/podinfo/annotations

View the files in the /etc/podinfo directory:

  1. /# ls -laR /etc/podinfo

In the output, you can see that the labels and annotations files are in a temporary subdirectory: in this example, ..2982_06_02_21_47_53.299460680. In the /etc/podinfo directory, ..data is a symbolic link to the temporary subdirectory. Also in the /etc/podinfo directory, labels and annotations are symbolic links.

  1. drwxr-xr-x  ... Feb 6 21:47 ..2982_06_02_21_47_53.299460680
  2. lrwxrwxrwx  ... Feb 6 21:47 ..data -> ..2982_06_02_21_47_53.299460680
  3. lrwxrwxrwx  ... Feb 6 21:47 annotations -> ..data/annotations
  4. lrwxrwxrwx  ... Feb 6 21:47 labels -> ..data/labels
  6. /etc/..2982_06_02_21_47_53.299460680:
  7. total 8
  8. -rw-r--r--  ... Feb  6 21:47 annotations
  9. -rw-r--r--  ... Feb  6 21:47 labels

Using symbolic links enables dynamic atomic refresh of the metadata; updates are written to a new temporary directory, and the ..data symlink is updated atomically using rename(2).

Note: A container using Downward API as a subPath volume mount will not receive Downward API updates.

Exit the shell:

  1. /# exit

Store Container fields

The preceding exercise, you stored Pod fields in a DownwardAPIVolumeFile. In this next exercise, you store Container fields. Here is the configuration file for a Pod that has one Container:

pods/inject/dapi-volume-resources.yaml Expose Pod Information to Containers Through Files - 图2

  1. apiVersion: v1
  2. kind: Pod
  3. metadata:
  4.   name: kubernetes-downwardapi-volume-example-2
  5. spec:
  6.   containers:
  7.     - name: client-container
  8.       image: k8s.gcr.io/busybox:1.24
  9.       command: ["sh", "-c"]
  10.       args:
  11.       - while true; do
  12.           echo -en '\n';
  13.           if [[ -e /etc/podinfo/cpu_limit ]]; then
  14.             echo -en '\n'; cat /etc/podinfo/cpu_limit; fi;
  15.           if [[ -e /etc/podinfo/cpu_request ]]; then
  16.             echo -en '\n'; cat /etc/podinfo/cpu_request; fi;
  17.           if [[ -e /etc/podinfo/mem_limit ]]; then
  18.             echo -en '\n'; cat /etc/podinfo/mem_limit; fi;
  19.           if [[ -e /etc/podinfo/mem_request ]]; then
  20.             echo -en '\n'; cat /etc/podinfo/mem_request; fi;
  21.           sleep 5;
  22.         done;
  23.       resources:
  24.         requests:
  25.           memory: "32Mi"
  26.           cpu: "125m"
  27.         limits:
  28.           memory: "64Mi"
  29.           cpu: "250m"
  30.       volumeMounts:
  31.         - name: podinfo
  32.           mountPath: /etc/podinfo
  33.   volumes:
  34.     - name: podinfo
  35.       downwardAPI:
  36.         items:
  37.           - path: "cpu_limit"
  38.             resourceFieldRef:
  39.               containerName: client-container
  40.               resource: limits.cpu
  41.               divisor: 1m
  42.           - path: "cpu_request"
  43.             resourceFieldRef:
  44.               containerName: client-container
  45.               resource: requests.cpu
  46.               divisor: 1m
  47.           - path: "mem_limit"
  48.             resourceFieldRef:
  49.               containerName: client-container
  50.               resource: limits.memory
  51.               divisor: 1Mi
  52.           - path: "mem_request"
  53.             resourceFieldRef:
  54.               containerName: client-container
  55.               resource: requests.memory
  56.               divisor: 1Mi

In the configuration file, you can see that the Pod has a downwardAPI Volume, and the Container mounts the Volume at /etc/podinfo.

Look at the items array under downwardAPI. Each element of the array is a DownwardAPIVolumeFile.

The first element specifies that in the Container named client-container, the value of the limits.cpu field in the format specified by 1m should be stored in a file named cpu_limit. The divisor field is optional and has the default value of 1 which means cores for cpu and bytes for memory.

Create the Pod:

  1. kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume-resources.yaml

Get a shell into the Container that is running in your Pod:

  1. kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh

In your shell, view the cpu_limit file:

  1. /# cat /etc/podinfo/cpu_limit

You can use similar commands to view the cpu_request, mem_limit and mem_request files.

Capabilities of the Downward API

The following information is available to containers through environment variables and downwardAPI volumes:

  • Information available via fieldRef:
    • metadata.name - the pod’s name
    • metadata.namespace - the pod’s namespace
    • metadata.uid - the pod’s UID
    • metadata.labels['<KEY>'] - the value of the pod’s label <KEY> (for example, metadata.labels['mylabel'])
    • metadata.annotations['<KEY>'] - the value of the pod’s annotation <KEY> (for example, metadata.annotations['myannotation'])
  • Information available via resourceFieldRef:
    • A Container’s CPU limit
    • A Container’s CPU request
    • A Container’s memory limit
    • A Container’s memory request
    • A Container’s hugepages limit (providing that the DownwardAPIHugePages feature gate is enabled)
    • A Container’s hugepages request (providing that the DownwardAPIHugePages feature gate is enabled)
    • A Container’s ephemeral-storage limit
    • A Container’s ephemeral-storage request

In addition, the following information is available through downwardAPI volume 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

The following information is available through environment variables:

  • status.podIP - the pod’s IP address
  • spec.serviceAccountName - the pod’s service account name, available since v1.4.0-alpha.3
  • spec.nodeName - the node’s name, available since v1.4.0-alpha.3
  • status.hostIP - the node’s IP, available since v1.7.0-alpha.1

Note: If CPU and memory limits are not specified for a Container, the Downward API defaults to the node allocatable value for CPU and memory.

Project keys to specific paths and file permissions

You can project keys to specific paths and specific permissions on a per-file basis. For more information, see Secrets.

Motivation for the Downward API

It is sometimes useful for a Container to have information about itself, without being overly coupled to Kubernetes. The Downward API allows containers to consume information about themselves or the cluster without using the Kubernetes client or API server.

An example is an existing application that assumes a particular well-known environment variable holds a unique identifier. One possibility is to wrap the application, but that is tedious and error prone, and it violates the goal of low coupling. A better option would be to use the Pod’s name as an identifier, and inject the Pod’s name into the well-known environment variable.

What’s next